Preguntas frecuentes

Verifacti es una solución diseñada para desarrolladores de software que necesitan adecuar sus sistemas de facturación a Veri*Factu, Ticketbai en el País Vasco y próximamente NaTicket en Navarra. Verifacti ofrece actualmente tres APIs diferenciadas y una plataforma web intuitiva y sencilla.API Veri*Factu

La API Veri*Factu permite cumplir con la normativa del sistema Veri*Factu de la Agencia Tributaria española. Se trata de una API REST en la nube que opera en tres pasos fundamentales:

1. Recepción de petición con los datos de una factura en formato JSON.
2. Devolución inmediata de una respuesta con el código QR correspondiente a la factura.
3. Generación inmediata del registro de facturación (XML) y remisión a la API de la administración, garantizando el cumplimiento de todos los requisitos normativos.

API TicketbaiLa API Ticketbai permite la adaptación al sistema Ticketbai exigido por las Haciendas Forales Vascas. Actualmente, existen tres sistemas Ticketbai distintos, uno para cada provincia del País Vasco. Con la API Ticketbai de Verifacti, se logra la adecuación a cualquiera de estas tres haciendas mediante una única integración.API de Gestión de NIFsLa API de Gestión de NIFs simplifica la creación, activación y desactivación de NIFs dentro de Verifacti, configuración de webhooks y gestión de modelos de representación automatizada. Esta API es especialmente beneficiosa para softwares con centenares o miles de obligados tributarios.Próximamente: Factura Electrónica y NaTicket

Verifacti continuará evolucionando con mejoras clave en el futuro:

• Factura electrónica: Cumplirá con los requisitos de la factura electrónica una vez se establezca el marco reglamentario necesario.
• Hacienda Navarra: Verifacti desarrollará una API específica para el sistema Navarro NaTicket cuando se establezca el marco reglamentario necesario.

Verifacti es una solución diseñada para desarrolladores y equipos técnicos que necesitan adaptar su software a los requisitos fiscales establecidos por la Agencia Tributaria (Veri*Factu) y/o las Haciendas Forales Vascas (Ticketbai). Verifacti es la solución ideal para:1. Comercializadores y distribuidores de software de facturaciónCualquier proveedor de software que contenga funcionalidad de facturación deberá asegurar el cumplimiento de los requisitos de Veri*Factu y Ticketbai. Entre los softwares sujetos a cumplimiento hay ERPs, CRMs, softwares de facturación, softwares de tipo SAAS, y en general cualquier software que incluya entre sus funcionalidades la emisión de facturas.2. Empresas o autónomos con sistemas informáticos de facturación propios.Veri*Factu será obligatorio también para obligados tributarios que usen un software propio para la emisión de facturas.

Te explicamos cuáles son los aspectos esenciales para adecuar tu software a Veri*Factu y cómo Verifacti te ayuda a cumplirlos (dentro del modo Veri*Factu):

• Generación del QR - Las facturas emitidas por tu software deben llevar el QR Veri*Factu => Cuando nos haces una llamada para comunicarnos la emisión de una factura, nuestra API te devuelve el QR de manera instantánea para que lo puedas pegar a la factura.

• Generación y remisión del registro de facturación - Cuando emites una factura, debe generarse (en el mismo momento) un fichero de tipo XML según los requisitos de la AEAT (el famoso "registro de facturación") y debe remitirse a la AEAT sin demora => Cuando nos haces una llamada para comunicarnos la emisión de una factura generamos el XML de manera síncrona instantánea, y remitimos a la AEAT dicho fichero con nuestro propio certificado digital.

• Comprobación de la respuesta de la AEAT - Una vez la factura ha sido enviada a la AEAT (proceso que puede durar unos pocos minutos) es importante comprobar la respuesta de la AEAT para descartar / arreglar errores => Verifacti facilita webhooks y endpoints específicos para conocer y gestionar las respuestas de la AEAT.

• Declaración responsable - Debes tener una declaración responsable accesible en un lugar visible para tus usuarios / clientes. => Verifacti te facilita una plantilla y materiales para completar este documento.

• Modelos de representación - Antes de enviar la primera factura de un obligado tributario que usa tu software a la AEAT debes gestionar la firma por parte del obligado tributario de un formulario muy sencillo que la AEAT publicó en el BOE en diciembre => Verifacti te facilita los formularios pre-rellenados con instrucciones claras para la firma, así como mecanismos sencillos para que puedas hacernos llegar el formulario (manualmente o via endpoint).

Hay 2 escenarios diferentes.

1. Plazos para software de uso propio
   Si tu software de facturación es para uso propio (para la emisión de tus propias facturas), entonces tu fecha sería:
• 1 de enero de 2026 si estás sujeto al impuesto de sociedades.
• 1 de julio de 2026 para los demás (autónomos principalmente)
2. Plazos para productores o comercializadores de software
Si eres productor o comercializador de software, tu software debe estar adecuado a partir del 29 de julio de 2025.
Excepción: software ya vendidos con contrato plurianual de mantenimiento, el plazo se alarga a los plazos de 2026 (ver arriba)
Dudas relativas al plazo del 29 de julio:
Estamos recibiendo muchas dudas respecto a cómo interpretar el plazo de vendedores de software. La AEAT ha publicado información al respecto aquí. Nuestra interpretación, tras leerlo detenidamente, es la siguiente:
• Software ya vendido a clientes antiguos antes del 29 de julio de 2025: clientes antiguos con contrato de mantenimiento plurianual podrían seguir usando un software no adaptado a Veri*Factu hasta que llegue su plazo (enero o julio de 2026).
• En el caso específico de SAAS, cabe preguntarse cómo aplica lo anterior para un software de tipo SAAS, dónde los usuarios (antiguos y nuevos) comparten la misma base de código. Nuestra interpretación tras varias consultas es la siguiente:
• Para clientes nuevos del SAAS adquiridos después del 29 de julio, debe haber cumplimiento con Veri*Factu.
• Para clientes anteriores al 29 de julio con contrato de mantenimiento plurianual puede no haber cumplimiento con Veri*Factu.
• Si se ofrece la opción de "pasarse" a Veri*Factu, no debería de darse la opción de deshacer esa decisión al usuario.

A ojos de la AEAT, una arquitectura que se apoya en una API como la de Verifacti es una arquitectura mixta con 2 componentes:

• CPF (Componente Principal de Facturación): tu SIF desde el cual se emiten las facturas.
• CEF (Componente Externo de Facturación): nuestra API.

Hay aspectos de la adecuación a Veri*Factu y responsabilidades que son ineludibles para el CPF (tu software), y que una solución como la nuestra os ayuda a cumplir pero que en última instancia dependen de nosotros. Te menciono algunos ejemplos:

• Envío en tiempo real de las facturas con datos correctos - Nosotros no sabemos cuando vuestros usuarios interactúan con vuestro software, os corresponde a vosotros el envío correcto en tiempo real.
• Publicación de la declaración responsable - Si bien nosotros os damos una plantilla y os guiamos, sois vosotros quienes debéis completar y asegurar la correcta publicación de la misma en vuestro software.
• Inclusión del QR en la factura - Si bien os facilitamos el QR, sois vosotros quienes debéis aseguraros de que se pega en la factura.

El principal motivo para utilizar una API como la de Verifacti es ahorrar innumerables horas de desarrollo en fases de integración y mantenimiento.Al utilizar la API de Verifacti, se evitan los principales retos de la integración directa con la administración, tales como:

• Documentación confusa e insuficiente.
• Uso obligatorio de XML como formato de comunicación.
• Restricciones de tiempo y frecuencia en las llamadas a la API de la administración.
• Firma obligatoria con certificado.
• Encadenamiento obligatorio de los registros de facturación.
• Generación y verificación de huellas/hash.

Verifacti destaca como una solución inmejorable para el reto Veri*Factu que te reducirá al mínimo el número de horas de desarrrollo y consultas para solucionar este reto:

• Soporte dedicado y personalizado para asegurar una integración fácil y correcta
• Documentación API sencilla y clara
• Sección de ejemplos de llamadas y peticiones y
• Sección de preguntas frecuentes hiper detallada
• Sirve también para Ticketbai y próximamente Navarra
• API de gestión de NIFs para alta y baja programática de tus usuarios
• Sistema de gestión automatizada de la representación vía API
• Webhooks para conocer las respuestas de la AEAT
• Sistema de validación de errores inteligente para evitar errores en la AEAT
• Comprobación destinatarios facturas para evitar errores en la AEAT
• Arquitectura serverless basada en contenedores, lo que permite un escalado automático en función de la carga

Nos distinguimos por participar activamente en la fase de integración, respondiendo con celeridad a las dudas de nuestros usuarios por teléfono y por email.Para cualquier duda podéis escribir a [email protected] con tus dudas, lo leen varias personas y obtendrás respuesta con rapidez. Agendaremos una llamada en caso de que sea necesario.Dispones además de recursos para minimizar los bloqueos y consultas a soporte que te animamos a consultar:

• Documentación API sencilla y clara: Veri*Factu, Ticketbai y gestión NIFs
• Sección de ejemplos de llamadas y peticiones
• Sección de preguntas frecuentes hiper detallada
• Canal de YT con vídeos cortos

Verifacti se puede integrar con cualquier stack tecnológico. El único requisito técnico es que tu stack sea capaz de realizar llamadas a una API REST en la nube. Esto es algo muy común y ampliamente soportado en cualquier lenguaje o framework moderno (y también en los más antiguos).Si no sabes cómo hacerlo, encontrarás fácilmente recursos en la web, en ChatGPT o en YouTube con tutoriales que explican cómo realizar llamadas a una API REST desde prácticamente cualquier tecnología. Es un procedimiento estándar, totalmente seguro y habitual en la integración de software.Además, tenemos clientes que ya han integrado Verifacti con éxito desde multitud de lenguajes, frameworks y ERPs. Entre ellos, destacan ejemplos como:

• Lenguajes de programación: Python, Java, C#, Visual Basic .NET, PHP, Ruby on Rails, Go, Rust, Kotlin, Swift, Objective-C, C++, Perl.
• Entornos JavaScript y frameworks: Node.js, Express, NestJS, React, Angular, Vue.js, Next.js, Nuxt.js, Svelte.
• Frameworks y stacks backend: Django, Flask, Spring Boot, Laravel, Symfony, CodeIgniter, ASP.NET Core, Grails.
• Entornos de integración empresarial / ERP: Odoo (módulos personalizados), Dolibarr, SAP, Microsoft Dynamics, Sage, Zoho, Oracle NetSuite.
• Sistemas de facturación y contabilidad: Holded, A3 Software, Factusol, ContaPlus.
• Automatización e integraciones: Zapier, Integromat (Make), n8n.
• Bases de datos y conectores: MySQL, PostgreSQL, SQL Server, MongoDB, Firebase, Redis.
• Otros entornos comunes: WordPress (con plugins), Magento, Shopify, WooCommerce, Prestashop.

En resumen, da igual si trabajas con tecnologías clásicas o modernas: Verifacti es compatible con cualquier stack tecnológico.

Puedes ver logos y testimonios de clientes en nuestra Home (página de inicio).

No existe un listado de softwares homologados para Veri*Factu por la AEAT. La obligación de certificación que establece la ley antifraude se resuelve mediante una autocertificación, es decir, una declaración responsable (ver otras preguntas frecuentes relacionadas). Aunque algunos proveedores y softwares de facturación afirman estar homologados por la AEAT, tal homologación no existe. Se trata de una estrategia comercial sostenida sobre una afirmación inexacta e incluso engañosa.Verifacti sí ha firmado con la AEAT un convenio específico de colaboración social (convenio 017) que nos permite utilizar nuestro propio certificado para remitir información fiscal a la AEAT en nombre de nuestros clientes. Ver listado de entidades con acuerdo aquí (aparecemos como Bilbabit SL).En Ticketbai, el sistema de las haciendas forales vascas, sí existe el concepto de software homologado por la Administración “software garante”. Nosotros también cubrimos Ticketbai y somos “software garante” es decir software homologado por la Administración en las tres provincias del País Vasco. Incluimos aquí el listado de softwares garantes de Vizcaya a modo de ejemplo.

Sí. Desde Verifacti también te ayudamos a cumplir con Ticketbai. Con muy poco trabajo de integración extra podrás cumplir con los requisitos de cualquiera de las haciendas forales del País Vasco. API para Ticketbai aquí.

Sí. Verifacti tiene intención de dar cobertura al sistema de Navarra NaTicket para cubrir la totalidad del territorio español.

Sí. Desde Verifacti tenemos la intención de dar respuesta a las necesidades que surjan en torno a la factura electrónica una vez se haya desarrollado el reglamento. Por el momento no es posible al no existir el desarrollo normativo necesario.

Aunque Verifacti no cuenta con una versión en inglés, Verifacti es utilizado fácilmente por desarrolladores de habla no hispana de la siguiente manera:

• Para todo lo disponible bajo el dominio verifacti.com, sencillamente hay que activar la traducción del browser.
• Para el canal de Youtube hay subtítulos en inglés.

Cumplir con Veri*Factu no garantiza el cumplimiento de todas las normativad de facturación ni de las normas contables o tributarias. Es frecuente encontrarse con situaciones en las que el sistema Veri*Factu acepta facturas con elementos incorrectos desde el punto de vista de la normativa de facturación.Un buen ejemplo de lo anterior es el requisito de secuencialidad de las facturas dentro de una misma serie que establece la normativa de facturación. Veri*Factu no dará error si enviamos facturas en orden no secuencial, a pesar de ser algo incorrecto y sancionable.Por eso no debe asumirse que una respuesta "correcta" de la AEAT a una llamada a su API a través de Verifacti equivalga a un visto bueno normativo total.

Para softwares con varios obligados tributarios, en la mayor parte de los casos Verifacti es contratado como proveedor por el desarrollador del software de facturación. Este desarrollador da de alta a los obligados tributarios en Verifacti, por lo que lo normal es que los obligados tribuarios no interactúen con Verifacti para nada.En lo relativo a cómo trasladar el coste a los obligados tributarios, esto es una decisión exclusiva del software de facturación. En este sentido hemos visto todo tipo de enfoques por parte de nuestros clientes:

• absorber el coste
• repercutir el coste
• incluir margen

Muy excepcionalmente tenemos softwares de facturación que optan por pedir a sus obligados tributarios que nos contraten directamente. En estos casos:

• Es recomendable que el software de un camino fácil al obligado tributario para introducir su API key única.
• Los precios podrían resultar más caros, puesto que no habría descuento por volumen alto de NIFs.

A ojos de la Administración Tributaria un ticket de compra equivale a una factura simplificada y las facturas simplificadas deben ser comunicadas a través del sistema Veri*Factu. En otras palabras, todos los tickets deben ser comunicados por el sistema Veri*Factu como facturas simplificadas

Puedes consultar nuestro DPA en nuestros términos de uso.

Verifacti tiene un SLA que está publicado en los términos de uso.

El entorno de producción de Veri*Factu está habilitado desde abril de 2025. Ya es posible enviar facturas reales a la AEAT.

La API de Verifacti para Veri*Factu está diseñada para facilitar el envío de información fiscal a la Agencia Tributaria, proporcionando una solución accesible a los desarrolladores de software de facturación. En lugar de integrarse directamente con la API de la administración, los desarrolladores pueden realizar sus peticiones a la API de Verifacti, evitando así complejidades tecnológicas y barreras técnicas.Facilidad y rapidezLa API de Verifacti está diseñada para ofrecer una integración sencilla y rápida gracias a:

• Documentación clara y concisa, con ejemplos y colecciones Postman.
• Uso de JSON como formato de comunicación.
• Sin límites de tiempo o número de llamadas a la API.
• Eliminación de necesidad de certificados propios, utilizando certificados de representación de Verifacti.
• Soporte técnico dedicado, especialmente en la fase de integración.

El flujo de funcionamiento de la API Verifacti sigue este esquema:

1. Cuando se emite una nueva factura en el software de facturación, se envía una petición a la API de Verifacti con:
• Una API key específica de la empresa emisora (NIF contribuyente).
• Un JSON con los datos de la factura (base imponible, IVA, total, etc.).
2. La API de Verifacti responde de inmediato con un QR en formato Base64, listo para ser incluido en la factura y entregado al destinatario.
3. La API de Verifacti genera de manera inmediata el registro de facturación (fichero XML) cumpliendo con todos los requisitos (inmediatez, encadenamiento, formato, inalterabilidad, integridad, trazabilidad, etc).
4. En los siguientes segundos/minutos, Verifacti envía la información a la API de la administración, que emite un XML de respuesta.
5. Se debe confirmar la respuesta de la AEAT para verificar si la factura fue aceptada o requiere correcciones:
• se puede hacer via webhook
• se puede realizar una llamada posterior al endpoint estado de registro

API Verifacti como reflejo fiel de Veri*FactuVerifacti ha diseñado su API para ser un reflejo fiel de la API de la administración, replicando:

• Los endpoints.
• La estructura de las llamadas.
• Los mensajes de error devueltos por la administración.

Esto significa que cualquier error devuelto por la API de Verifacti proviene, salvo excepciones, directamente de la administración. Esto permite a los desarrolladores identificar problemas con mensajes originales de la Agencia Tributaria y corregirlos sin intermediarios.Al no actuar como un intérprete de los requisitos de Hacienda, Verifacti asegura una integración transparente y alineada con los criterios oficiales, permitiendo a los desarrolladores centrarse en la implementación sin incertidumbres.

Cuando hagas una petición a nuestra API con los datos de una factura nueva recibirás una respuesta síncrona instantánea con el QR de la factura en formato imagen Base64 para que lo puedas pegar a la factura. Más información en sección específica de las preguntas frecuentes.

Se usará nuestro certificado. No es necesario que nos facilites tu certificado o el de los obligados tributarios que usen tu software. Verifacti es colaborador social con acuerdo 017 con la AEAT y estamos facultados para usar nuestro propio certificado para el envío de la información fiscal a la AEAT. Más información en sección específica de las preguntas frecuentes.

Verifacti os facilitará una plantilla para completar la declaración responsable y materiales de ayuda para completarla. Más información en sección específica de las preguntas frecuentes.

No. Tú únicamente nos haces peticiones en JSON a nuestra API. Nosotros nos encargamos del resto: primero te damos el código QR y luego generamos la huella de encadenamiento, gestionamos los encolamientos y enviamos tu información fiscal a la AEAT en formato XML con un certificado digital.

En el caso de Veri*Factu la administración ha impuesto unos límites a la cantidad y tiempos de las peticiones que se puede realizar a la AEAT y es frecuente que una petición realizada a nuestra API tarde hasta 100 o 200 segundos en ser remitida a la administración. Por ese motivo nuestra API devuelve el QR de manera inmediata y posteriormente tarda uno o dos minutos en hacer llegar el registro de facturación a la administración. Esto es correcto y es la manera que ha elegido la AEAT para gestionar las peticiones a su API.En el caso de Ticketbai la respuesta es inmediata e incluye tanto el QR como la huella.

Es común escuchar que con el sistema Veri*Factu las facturas no pueden modificarse. Esta percepción es errónea. La inalterabilidad exigida por Veri*Factu se refiere a los registros de facturación (XMLs generados por Verifacti), no a las facturas en sí mismas. Los registros de facturación son los XML que genera Verifacti a partir de las llamadas realizadas a la API. Por cada llamada realizada a la Agencia Tributaria hay un XML (registro de facturación) y estos no pueden modificarse a posteriori una vez creados.No obstante, sí es posible modificar una factura ya generada a través de registros de facturación adicionales. En concreto, las modificaciones pueden realizarse mediante los endpoints de anulación, subsanación o (sobre todo) mediante la emisión de facturas nuevas facturas rectificativas o de abono.Más información en la sección específica de las preguntas frecuentes.

El requisito de trazabilidad exigido por Veri*Factu se refiere al encadenamiento de registros de facturación, no a la secuencialidad de las facturas en sí. En otras palabras, la administración exige que, con cada llamada a su API (XML), se incluya una referencia a la llamada anterior realizada, independientemente de que esta corresponda o no a la creación de una factura.El XML exigido por la administración en cada llamada, y que la API de Verifacti genera a partir del JSON recibido, se encarga automáticamente de este encadenamiento. Los usuarios de la API Verifacti no deben preocuparse por esto.La trazabilidad no debe ser confundida con el requisito de secuencialidad de la numeración de una factura dentro de la misma serie, cuestión que no tiene nada que ver con Veri*Factu.

Registro de facturación y factura no es lo mismo.Los registros de facturación son los XML que genera Verifacti a partir de las llamadas realizadas a la API. Por cada llamada realizada a la Agencia Tributaria hay un XML (registro de facturación).Una factura puede tener uno o varios registros de facturación.

• En un primer momento, al crearse una factura nueva, habría un único registro para esa factura.
• Si posteriormente se hacen otras llamadas relacionadas con la misma factura (por ejemplo, una llamada al endpoint de subsanación) habría más de un registro para la misma factura.

La administración ofrece dos caminos para cumplir con el sistema Veri*Factu: el modo Veri*Factu y el modo No-Veri*Factu.

• El modo Veri*Factu consiste en el envío en tiempo real a la administración de los registros de facturación.
• En el modo No-Veri*Factu los registros sí se deben generar en tiempo real, pero no se envían a la AEAT, quedan conservados por el software de facturación

El modo No-Veri*Factu no está cubierto por la API debido a la nula demanda que hemos recibido de esta manera de cumplir con la normativa. Estos son algunos de los inconvenientes del modo No-Veri*Factu:

1. Obligación de conservación: En el modo No-Veri*Factu, el contribuyente no envía las facturas a la administración en tiempo real, lo que genera una obligación de conservación de los registros de facturación. Esto implica que el software de facturación debe estar preparado para enviar toda la información fiscal del contribuyente en caso de requerimiento por parte de la Agencia Tributaria.
2. Requisitos adicionales: ir por este camino implica requisitos técnicos adicionales como la necesidad de contar con un registro de eventos.
3. Inspecciones Fiscales: La administración ha indicado que los contribuyentes que opten por el modo No-Veri*Factu tendrán una mayor probabilidad de sufrir inspecciones fiscales.
4. Opción Temporal: La administración ha expresado que el modo No-Veri*Factu es una opción temporal destinada a desaparecer en el futuro.

En modo Veri*Factu, no existe la obligación de conservar los registros de facturación enviados a la Agencia Tributaria, ni para el software de facturación ni para el contribuyente, puesto que dichos registros ya han sido remitidos previamente. La administración es clara a este respecto: la obligación de conservación de registros de facturación solo existe en el modo No-Veri*Factu.

Estas son algunas capacidades y funcionalidades de la API:

• Generación de QR
• Generación de XML (incluyendo encadenamiento y huella)
• Gestión de certificados
• Lógica de reintento si la API de AEAT está inactiva
• Transmisión por lotes
• Cumplimiento de la API de Ticketbai incluido en el precio
• Validación inteligente para evitar el envío de XMLs que generen errores, evitando la necesidad de peticiones posteriores para corregir errores
• Verificación del destinatario de la factura para evitar errores con la AEAT
• API de gestión de NIF para el registro y baja programática de usuarios
• Webhooks para recibir respuestas de la AEAT
• Sistema de gestión de representación automatizada a través de API
• Arquitectura sin servidor basada en contenedores, permitiendo escalado automático según la carga
• Documentación de API simple y clara

Verifacti funciona con un modelo de suscripción con pagos recurrentes mensuales o anuales según tu plan.El coste (mensual o anual) de la API Verifacti depende fundamentalmente del número de NIFs que tengas activos en el entorno de producción (número de contribuyentes reales).Tienes una cuenta gratuita para realizar la totalidad o la mayor parte de la integración. Sólo comenzarás a pagar cuando comiences a enviar facturas al entorno real de producción de la AEAT.

En Verifacti hablamos de manera indistinta de NIF, empresa, contribuyente u obligado tributario. Cada NIF dentro de Verifacti representa un contribuyente cuya información fiscal (facturas) quiere enviarse a la administración.Cuando hablamos de número de NIFs, nos referimos al número de usuarios obligados tributarios de vuestro software de facturación:

• Si vendéis software o lo implantáis, se refiere a los usuarios de vuestro software de facturación, es decir, a aquellos usuarios vuestros que emiten facturas usando vuestro software (número de contribuyentes individuales que emiten facturas con vuestro software).
• Si se trata de adecuar vuestro propio software interno, con el que emitís vuestras propias facturas, entonces sería un único NIF (el vuestro propio), o varios NIFs si sois un grupo de empresas.

Un caso especial es el de la emisión de facturas en nombre de destinatario (autofactura) o terceros. En estos casos, el número de NIFs coincide con los obligados tributarios sujetos pasivos del IVA, es decir, aquellos que venden un producto o un servicio.

Para un número bajo de NIFs, los precios están disponibles en la página de precios.Para un número elevado de NIFs podemos hacerte una propuesta en función de tus necesidades (usar para ello el formulario de contacto). De cara a enviarte información relevante y una propuesta ajustada así como para resolver tus dudas, necesitamos conocer los siguientes datos:

1. ¿El software que vas a integrar es para uso propio de tu empresa o es un software que vendes/distribuyes a terceros?
2. ¿Cuál es el número aproximado de NIFs emisores de facturas con tu software? (número de obligados tributarios que emiten facturas con vuestro software)
3. ¿Cuál es el número aproximado de facturas emitidas con tu software? (por ejemplo, rango de número de facturas emitidas aproximado por mes o por año por NIF)

Todos los planes de Verifacti incluyen un límite de seguridad muy elevado de facturas por NIF y por mes.

• Se trata de límite de seguridad, pensado para que no se sobrepase nunca o casi nunca.
• Para los planes anunciados en la página de precios, el límite actual es de 3000 facturas por NIF y por mes. Para planes customizados, el límite puede ser diferente.
• En caso de superarse esta cifra, la operativa no se interrumpe, sencillamente se añade a la factura de Verifacti una cantidad variable por las facturas adicionales no cubiertas por el plan. Este coste es para los planes anunciados en la página de precios de 2 Euros por cada 1000 facturas adicionales.
• En caso de que este límite no sea suficiente para ti, contáctanos y te haremos una oferta personalizada.

Si pagas por adelantado un año de uso, entonces hay unos descuentos del 10%. Esto exige el prepago por adelantado de los 12 meses para cada NIF que añadas. El año se contaría desde la fecha en la cual creaste tu suscripción anual (fecha en la cual te convertiste en cliente de pago), o desde la última fecha de renovación de tu plan anual.

La dinámica de pagos a medida que se crean / activan o desactivan NIFs es la siguiente.Para planes MENSUALES

• Primero hay que generar una suscripción de pago eligiendo la opción "Mes". En ese momento se os cobra por un único NIF. Pongamos que es el día 15 de septiembre.
• A partir de ahí, cada 15 de cada mes se cobrará el mismo importe equivalente a 1 NIF.
• Cuando crees tu primer NIF en producción no se te cobra nada, porque ya estás pagándolo.
• Cuando crees tu segundo NIF en producción, entonces no se te cobra nada en ese momento, pero en el siguiente día 15 se te cobrará el tiempo consumido por ese segundo NIF en el mes anterior (pago a posteriori por el consumo realizado de ese NIF prorrateado) y un mes completo por adelantado (pago a priori de un mes completo)
• A partir de ahí se os cobrarían 2 NIFs cada mes (pre-pago)
• Misma dinámica con cada aumento de NIFs
• Si en cualquier momento desactivas un NIF, sencillamente cuando llegue el momento del siguiente cobro no se cobrará ese NIF. No hay devolución por el importe pagado y no utilizado por ese NIF.

Para planes ANUALES

• Primero hay que generar una suscripción de pago eligiendo la opción "Año". En ese momento se os cobra por un único NIF por todo el año. Pongamos que es el día 15 de septiembre.
• Cuando se den de alta NIFs adicionales, entonces se cobrará en el momento del alta el importe total anual prorrateado por el tiempo que queda hasta el siguiente 15 de septiembre. Es decir, si el alta de un NIF se produce el 15 de marzo, quedarían 6 meses para completar el ciclo de un año, y se cobrarían 6 meses por adelantado por el derecho a usar ese NIF durante los 6 meses siguientes.
• El siguiente 15 de septiembre se cobrará el importe anual total de todos los NIFs activos en producción en ese momento.

Sí. Cuando pagas por un NIF en producción puedes elegir si ese NIF va por la vía de Ticketbai o Veri*Factu sin que afecte al coste.

Sí. Contamos con una API para gestionar la activación y desactivación de NIFs, webhooks y gestión automatizada de modelos de representación. Todo ello está incluido en el precio.

No. Pagarás solamente lo que uses y el tiempo que lo uses. No tendrás que pagar ningún coste de instalación y podrás dejar de usar el servicio cuando quieras.

No. Los precios de Verifacti son por contribuyente (NIF) e independientes del número de TPVs y/o locales desde los cuales se emitan las facturas. Somos una API en la nube que no requiere instalación local de software de ningún tipo.

Verifacti ofrece un sandbox o cuenta gratuita con una empresa de prueba para que puedas probar la API y realizar la integración.1. Crear cuenta gratuita en VerifactiRegístrate en pocos segundos en Verifacti. Solo tienes que acceder a Verifacti, hacer clic en Crear Cuenta, ingresar tu email y una contraseña. Tras este paso, estarás listo para explorar la plataforma.2. Accede a la empresa de pruebaTu cuenta gratuita incluye una empresa de prueba, que te permite realizar llamadas al entorno de prueba de la administración. Para acceder:

• Dirígete a la sección de Empresas.
• Haz clic sobre la empresa de prueba para ingresar a su panel de control.
• Esta empresa de prueba está incluida en el plan gratuito y es suficiente para la mayoría de los casos de integración con Verifacti.

3. Realiza tus primeras llamadas desde la terminalDentro del panel de tu empresa de prueba:

• Haz clic en Terminal en el menú lateral.
• Desde aquí podrás realizar llamadas a los distintos endpoints de la administración a través de Verifacti.
• Selecciona un tipo de llamada en el desplegable.
• Envía la llamada de prueba a la administración haciendo clic en Enviar.
• Si pruebas el endpoint de Crear factura, recibirás una respuesta inmediata con el QR listo para pegar en la factura.

4. Explora la sección de registrosTras realizar una llamada al endpoint de Crear factura, dirígete a la sección de Registros para consultar la información de la petición:

• Imagen del QR y su link asociado.
• JSON generado en la petición.
• XML enviado a la administración por Verifacti.
• XML de respuesta de la administración.

5. Utiliza la API keyEn la sección de Configuración, encontrarás la API key de tu cuenta de prueba. Utilízala para realizar llamadas a la API directamente desde tu propio código.

Las siguientes funcionalidades requieren una suscripción de pago equivalente al coste de un único NIF en producción.:

• API de gestión de NIFs
• Webhooks
• Gestión automatizada de modelos de representación
• Creación de múltiples NIFs en entorno de test

Es posible acceder a todas estas funcionalidades creando una suscripción de pago por el precio simbólico equivalente a un NIF en producción. Una vez generada la suscripción de pago toda esa funcionalidad pasa a estar disponible.Para poder crear NIFs en entorno de producción también hace falta crear una suscripción de pago. Al aumentar el número de NIFs en producción la factura subirá.

No necesariamente. El plan gratuito cuenta con una empresa ya creada en el entorno de test desde la cual puede hacerse la integración sin coste.Sin embargo, hay algunas funcionalidades muy útiles (especialmente para clientes con volúmenes altos de NIFs) que requieren una suscripción de pago:

• API de gestión de NIFs
• Webhooks
• Gestión automatizada de modelos de representación
• Creación de múltiples NIFs en entorno de test

Es posible acceder a todas estas funcionalidades creando una suscripción de pago por el precio simbólico equivalente a un NIF en producción. Una vez generada la suscripción de pago toda esa funcionalidad pasa a estar disponible.

Los registros de facturación en entorno de test, al igual que en producción, no se pueden borrar. Esto tiene sentido: el modo test funciona exactamente igual que el modo prod, en el cual no se pueden borrar registros de facturación.Sí sería posible anular todas las facturas con el endpoint de anulación, pero eso no eliminaría los registros, y esos números de factura no podrían ser reutilizados.

El NIF de prueba gratuito tiene esa limitación: al ser un NIF compartido por muchos de nuestros usuarios hemos capado el acceso a ese endpoint para impedir que se compartan datos entre usuarios.

Para trabajar con Ticketbai, es necesario crear una suscripción de pago y crear un NIF nuevo marcando la opción Ticketbai.

Si has recibido una oferta por email, contacta a la persona que te envió la propuesta por email.Si no has recibido una oferta por email, entonces los pasos a seguir son los siguientes:

1. Acceder a la plataforma con usuario y contraseña
2. Navegar a esta página
3. Hacer click en "Comprar primer NIF" y seguir los pasos.
4. Asegurarse de marcar el checkbox de "empresa" y meter datos de empresa (nombre, NIF, etc).
5. Introducir datos de pago: se cobrará el coste de un NIF en producción en ese momento

A partir de ese momento ya seréis clientes de pago:

• Se os seguirá cobrando el coste equivalente al primer NIF al mes a partir de ese momento
• Si activáis el primer NIF en producción no se os cobrará nada
• Si activáis más NIFs en producción entonces vuestra factura irá aumentando en función del número de NIFs activados
• A medida que añadís NIFs, el coste unitario por NIF va bajando (el primero es el más caro, luego bajan rápidamente)

Verifacti, al igual que la mayoría de servicios de tipo SAAS en la nube, tiene unos términos de uso a los cuales los clientes quedan adheridos al suscribir un plan de pago. Estos términos detallan los derechos y obligaciones legales de las partes, así como el SLA, DPA y otros elementos legales.También contamos con nuestra "declaración responsable" pública, que establece nuestras responsabilidades dentro de la arquitectura mixta que conformamos junto a nuestros clientes.

Sí, cualquier persona o entidad puede contratar Verifacti, sea persona física o persona jurídica.

Te indicamos como asegurarte de que tus datos fiscales aparecen en la factura que Verifacti te emite a ti. Puedes introducir tus datos de facturación de dos maneras diferentes.Desde el área de Facturación

1. Entra en Verifacti con tu cuenta y navega a Facturación
2. Haz click en Acceder a tu portal de facturación
3. En el apartado Datos de facturación haz click en Actualizar datos

Al comprar tu suscripciónEn el proceso de compra, tras elegir el método de pago, deberías de ver un checkbox que dice "Soy empresa". Haz click ahí y podrás introducir tus datos de facturación.

En Verifacti hay dos tipos de API keys que se obtienen de manera diferente.API key de NIFCada obligado tributario para el cual se busca remitir facturas a la AEAT debe ser dado de alta en Verifacti y tendrá una API key única por entorno. Idealmente, habrá dos API keys por NIF: una para el entorno de test, y otra para el entorno de producción.Esta API key es esencial para las llamadas a la API. Esta API key permite:

• Identificar al contribuyente (sujeto pasivo de IVA) que figura en la factura como vendedor de un producto o servicio.
• Determinar el entorno de la administración al que se debe enviar la información fiscal (test vs. producción).
• Determinar la hacienda (AEAT vs. Haciendas Forales) a la que pertenece el contribuyente.

En Verifacti hay dos entornos: test y producción. Al añadir una empresa (un NIF) dentro de Verifacti hay que especificar el entorno (test o producción). Esa variable de entorno de la empresa en Verifacti definirá a qué entorno de la administración se envían las peticiones relativas a esa empresa.

• En entorno de test, la API key de la empresa empieza por vf_test_
• En entorno de producción, la API key de la empresa empieza por vf_prod_

Dependiendo de cada caso de uso, se requerirán más o menos API keys de este tipo:

• Los distribuidores y comercializadores de software requerirán múltiples NIFs, uno por usuario o contribuyente.
• Las empresas independientes solamente necesitarán crear API keys en test y prod para su propio NIF (o varios NIFs si son un grupo de empresas).

Las API keys de NIFs se pueden generar de dos maneras:

1. Manualmente desde la pantalla de inicio. Haz click en "Añadir empresa" y sigue los pasos.
2. A través de la API de gestión de NIFs. Ver documentación.

Las API keys pueden consultarse de dos maneras:

• Desde la sección de configuración dentro de cada NIF.
• También pueden obtenerse con la API de gestión de NIFs, endpoint API key de NIF.

Para crear NIFs nuevos es necesario contar con una suscripción de pago.

• Una suscripción de pago por el coste equivalente a 1 NIF en producción da la capacidad de contar con múltiples NIFs en el entorno de prueba sin que el coste aumente.
• Con la suscripción de pago creada, es posible crear NIFs en entorno de producción, y la factura se ajustará al alza

API key para la API de gestión de NIFsPara la utilización de la API de gestión de NIFs (altas y bajas de NIFs, webhooks, modelos de representación) es necesaria una API key específica que se obtiene aquí.Para acceder a esta API key es necesario contar con una suscripción de pago. Cualquier suscripción de pago, independientemente del coste o número de NIFs en producción de la misma, proporciona una API key para la API de gestión de NIFs y la capacidad de contar con múltiples NIFs en el entorno de prueba.

En ese caso, simplemente debes crear un nuevo NIF en nuestra plataforma y desactivar el anterior.

Las API keys no caducan.

Verifacti cuenta con una API específica para gestionar NIFs. Si tienes muchos obligados tributarios usando tu software, esta API es esencial para una integración exitosa.

La declaración responsable es una autocertificación en la cual el SIF confirma que cumple con la normativa. El requisito de "certificación" que establece la Ley Anti-Fraude (de dónde proviene Veri*Factu) queda satisfecho con esta "autocertificación" que cada software de facturación debe publicar, y que la AEAT puede exigir en caso de inspección.Para cumplir con Veri*Factu no hay requisitos de homologación externa ni verificación por parte de la AEAT. Sencillamente, cada software de facturación debe incorporar este documento, regulado en el Capítulo IV de la Orden Ministerial.En un caso de arquitectura mixta como el que resulta de usar una API como Verifacti, tanto el software de facturación como el propio Verifacti deben contar con su declaración responsable. La nuestra está disponible:

• A través de un link
• Vía endpoint

Hay un apartado completo en las preguntas frecuentes de la AEAT sobre este documento y sus requisitos. Aquí solo destacamos dos aspectos muy importantes de este document:

1. Emplazamiento de la declaración responsable - Debe ser visible para los usuarios del software y, en caso de comercialización, también para los compradores. Se sugiere que esté accesible en la sección de ayuda en los softwares de tipo web.

1. Numeración del software - La declaración responsable debe referirse al número de software correspondiente. Cada proveedor debe contar con una declaración para cada numeración de software creada después de la entrada en vigor de Veri*Factu. Solo debe estar disponible la declaración vigente, correspondiente a la numeración de software en uso, aunque en caso de inspección la AEAT podría solicitar todas las anteriores.

La AEAT ha publicado un ejemplo de declaración responsable en PDF.Nosotros hemos adaptado este ejemplo para nuestros usuarios. Lo puedes descargar aquí:

• Proporcionamos un documento de Word editable.
• Incluimos notas informativas para los apartados más complicados.
• Añadimos una sección para explicar el papel de la API Verifacti.

Información clave para rellenar el documento:

1. Los títulos de sección están en negrita y con letra más grande.
2. Sustituye las respuestas de ejemplo con tus propios datos.
3. Borra las notas informativas al completar el documento.

Es obligatorio mencionar a Verifacti como componente externo. Hemos incluido una sección específica para arquitecturas mixtas con componente externo. Debéis indicar nuestro número de versión de software vigente, que puede cambiar. Contáis con un endpoint específico para obtener nuestra declaración y el número de versión vigente.

No existe un listado de softwares homologados para Veri*Factu por la AEAT. La obligación de certificación que establece la ley antifraude se resuelve mediante una autocertificación, es decir, una declaración responsable (ver otras preguntas frecuentes relacionadas). Aunque algunos proveedores y softwares de facturación afirman estar homologados por la AEAT, tal homologación no existe. Se trata de una estrategia comercial sostenida sobre una afirmación inexacta e, incluso engañosa.En Ticketbai, el sistema de las haciendas forales vascas, sí existe el concepto de software homologado por la Administración “software garante”. Nosotros también cubrimos Ticketbai y somos “software garante” es decir software homologado por la Administración en las tres provincias del País Vasco. Incluimos aquí el listado de softwares garantes de Vizcaya a modo de ejemplo.

Ver preguntas específicas de la AEAT al respecto.

Te remitimos a las instrucciones disponibles en la plantilla del documento.

El QR en el sistema Veri*Factu es una URL codificada, única para cada factura, que se encuentra en la web de la Agencia Tributaria. Esta URL permite verificar si la factura ha sido recibida por la administración a través del sistema Veri*Factu. La administración espera que todas las facturas emitidas por contribuyentes sujetos al sistema Veri*Factu incluyan este QR. Así, cualquier receptor de una factura con un QR puede acceder fácilmente a la URL desde su dispositivo móvil y comprobar que la factura ha sido comunicada a la Agencia Tributaria.El QR se genera a partir de los siguientes 5 campos de la factura:

• NIF emisor
• Serie
• Número
• Fecha de expedicion
• Importe

Cuando se hace una llamada de factura nueva a la API de Verifacti la respuesta síncrona instantánea incluye el QR en formato imagen Base64.

La generación del QR es sencilla. Aunque la API Verifacti proporciona el QR inmediatamente al generar una nueva factura, muchos usuarios prefieren generarlo ellos mismos y añadirlo a la factura, ya que existen librerías de generación de QR en casi todos los lenguajes de programación.

Existen librerías y funciones en todos los stacks tecnológicos para transformar el QR en imagen Base64 que devuelve la API en una imagen para poder pegarla a la factura.

Para el caso concreto SAAS que usan Stripe para suscripciones el flujo puede ser:

1. Llega el evento invoice.payment_succeeded, que trae el objeto invoice.
2. Hacer una llamada a nuestra API y recoger el QR.
3. En el objeto invoice está el PDF de stripe, en invoice.invoice_pdf. Se descarga, se pega el QR y se sube a un S3.
4. Al cliente se le enseña el PDF propio, no el de Stripe.

En cuanto al PDF, se pueden hacer dos cosas:

1. Usar una librería, pero aún así es costoso dejar todos los casos bien
2. Usar el propio PDF de stripe y simplemente modificarlo. Esto es realmente fácil y rápido.

Si no has guardado el QR en tu base de datos, puedes realizar una llamada adicional al endpoint de estado de registro para recuperarlo. Para ello, es necesario que hayas guardado el UUID de la petición con la que creaste la factura. Recuerda que con Veri*Factu solo es necesario incluir el QR en la factura; no es necesario incluir ni conservar la huella, a menos que ofrezcas servicios no-Veri*Factu.

Con Veri*Factu no es necesario incluir la huella en la factura, con el QR es suficiente. La huella sí debe ir incluida en el XML que se envía a la administración. La generación de dicho XML (con la huella) y su envío a la administración son responsabilidad de Verifacti.Con Ticketbai sí es necesario incluir la huella y forma parte de la respuesta de la API.

En modo Veri*Factu, no existe la obligación de conservar los registros de facturación enviados a la Agencia Tributaria, ni para el software de facturación ni para el contribuyente, puesto que dichos registros ya han sido remitidos previamente. La administración es clara a este respecto: la obligación de conservación de registros de facturación solo existe en el modo No-Veri*Factu.Por registro de facturación, la administración entiende los ficheros XML que genera Verifacti a partir de las llamadas recibidas, y que se remiten a la AEAT. Se trata, por tanto, de los ficheros XML de petición a la administración y de respuesta de la administración. En modo Veri*Factu, no existe la obligación de conservar dichos ficheros.Dicho esto, Verifacti facilita endpoints para descargar los registros de facturación para aquellos usuarios que deseen guardarlos.Endpoint exportar XMLsEndpoint descargar XMLAsimismo, Verifacti guardará esta información para todos los NIFs activos en producción y un tiempo corto después (ver términos de uso).Lo anterior no debe confundirse con la obligación de conservación de facturas derivada del Reglamento de Facturación u otras normas tributarias o contables. Cualquier obligación que el software o sus usuarios (los contribuyentes) tuvieran antes de la aparición del sistema Veri*Factu sigue vigente. Sí existe por lo tanto obligaciones de conservación en lo relativo a las facturas, tal y como ya venía sucedienco antes de la normativa de Veri*Factu.

Toda la información relativa a un NIF (obligado tributario) se conserva mientras esté activo en el entorno de producción. Una vez deja de estar activo, pasado un tiempo corto (ver términos de uso) no garantizamos la custodia de esos datos.Verifacti facilita endpoints para descargar los registros de facturación para aquellos usuarios que deseen guardarlos.Endpoint exportar XMLsEndpoint descargar XML

Puedes acceder a los datos de un NIF de dos maneras diferentes:

1. Vía endpoint - Verifacti facilita endpoints para descargar los registros de facturación para aquellos usuarios que deseen guardarlos.
Endpoint exportar XMLs
Endpoint descargar XML
2. Interfaz web - Puedes consultar los últimos registros a través de la interfaz web, desde la pantalla de registros de cada uno de los NIFs.

Verifacti utiliza su propio certificado digital para remitir información a la AEAT en nombre de terceros. La AEAT exige la firma de un modelo de representación por parte de los obligados tributarios.Certificado de Verifacti como colaborador socialVerifacti emplea un certificado digital propio de representación para enviar la información fiscal a la administración en nombre de los obligados tributarios. Se evita así la necesidad de solicitar certificados y contraseñas a los usuarios de Verifacti, reduciendo riesgos de seguridad y evitando el rechazo de los usuarios a compartir credenciales sensibles. Para ello, Verifacti opera dentro del marco de la colaboración social, una figura previa a Veri*Factu muy extendida para multitud de usos de asesoramiento fiscal. En concreto, Verifacti ha firmado el convenio 017 con la AEAT, creado específicamente para dar cobertura a la figura de la colaboración social en el ámbito de Veri*Factu. Verifacti aparece listado (Bilbabit SL) en el listado oficial de entidades con acuerdo de la AEAT.Modelos de representaciónSiempre que no sea el propio obligado tributario el que remita su información a la AEAT, la norma exige que los contribuyentes firmen un modelo de representación en el que facultan a Verifacti a enviar información fiscal en su nombre. Estos modelos de representación fueron publicados en el BOE en diciembre de 2024 (ver Anexos I, II y III).Verifacti ofrece a sus clientes dos caminos diferentes para agilizar la firma de estos modelos de representación:

1. Desde la interfaz web de Verifacti, siguiendo los pasos indicados en la sección Configuración → Representación para cada NIF.
2. Programáticamente, a través de la API de gestión de NIFs.

Es muy importante destacar que el modelo de representación solo debe gestionarse una única vez por NIF. Es decir, si se quiere tener el mismo NIF dado de alta 2 veces en test y en producción, bastaría hacer esta gestión una sola vez en test para que valga también para el NIF de producción, incluso si este no ha sido creado todavía. Por lo tanto, la cronología adecuada para gestión de representación podría ser la siguiente:

1. Crear NIF en test
2. Gestionar representación para ese NIF
3. Crear NIF en producción (la representación ya estará gestionada sin necesidad de volverlo a hacer).

Verifacti opera dentro del marco de la colaboración social, una figura previa a Veri*Factu muy extendida para multitud de usos de asesoramiento fiscal. En concreto, Verifacti ha firmado el convenio 017 con la AEAT, creado específicamente para dar cobertura a la figura de la colaboración social en el ámbito de Veri*Factu. Verifacti aparece listado (Bilbabit SL) en el listado oficial de entidades con acuerdo de la AEAT.

Es muy importante destacar que el modelo de representación solo debe gestionarse una única vez por NIF. Es decir, si se quiere tener el mismo NIF dado de alta 2 veces en test y en producción, bastaría hacer esta gestión una sola vez en test para que sea válido también para el NIF de producción, incluso si este no ha sido creado todavía.Por lo tanto, la secuencia adecuada para gestión de representación podría ser la siguiente:

1. Crear NIF en test
2. Gestionar representación para ese NIF
3. Crear NIF en producción (la representación ya estará gestionada sin necesidad de volverlo a hacer).

La AEAT ha sido clara en que la manera correcta de firmar los modelos es o bien presencialmente o bien mediante un certificado digital. Somos conscientes de que este flujo no es el más amigable puesto que algunos obligados tributarios no tienen certificado digital. Si se producen cambios que permitan un camino más sencillo, notificaremos a todos nuestros clientes al respecto.

Verifacti ofrece a sus usuarios una plataforma web que permite:

• Explorar Verifacti e integrar el software utilizando una cuenta gratuita.
• Crear, activar y desactivar empresas (NIFs).
• Realizar llamadas desde la terminal.
• Acceder a documentación, preguntas frecuentes y recursos de integración.
• Consultar facturas y registros de facturación.

En la pantalla de inicio se pueden ver todos los NIFs creados, más el de test que venía incluido en la cuenta gratuita, separados en pestañas: test vs. producción. Pinchando en un NIF se accede a su panel de control individual:

• Inicio: Visualización de gráficos con información sobre la facturación del NIF.
• Facturas: Consulta de todas las facturas emitidas para el NIF, en una tabla filtrable por fecha y otros criterios.
• Registros: Acceso a todos los registros de facturación enviados a la Agencia Tributaria, incluyendo cualquier petición realizada a la administración a través de Verifacti.
• Terminal: Realización de llamadas a la administración para este NIF, con ejemplos de peticiones en el lado izquierdo y la respuesta de la API en el lado derecho.
• Configuración: Introducción de datos de la empresa y acceso a la API key, necesaria para realizar peticiones para este NIF.

Con estas funcionalidades, la plataforma Verifacti facilita la gestión y automatización de los procesos de facturación con la administración tributaria.

Verifacti no ofrece funcionalidad para invitar a miembros del equipo a una cuenta. Solamente hay unas credenciales por cuenta en Verifacti.

En el caso de comercializadores y distribuidores de software, Verifacti no está pensado para compartir el acceso con los obligados tributarios, puesto que con un acceso podría verse la información privada de otros obligados tributarios.Sin embargo, sería muy fácil replicar las pantallas de registros o facturas en el propio software usando la información de la propia base de datos del software y/o endpoints que facilitan el acceso a la información ahí disponible:

• Listar facturas
• Exportar XMLs

Una integración exitosa debe contemplar los siguientes aspectos:Revisar materiales clave

• Documentación API sencilla y clara: Veri*Factu, Ticketbai y gestión NIFs
• Sección de ejemplos de llamadas y peticiones
• Sección de preguntas frecuentes hiperdetallada
• Canal de YT con vídeos cortos

El 99% de las dudas se resuelven en estos materiales.Confirmar capacidad de hacer llamadas a una API RESTPara integrar con nosotros es preciso ser capaz de hacer llamadas a una API Rest. Muchos desarrolladores no se han enfrentado a este reto. De ser así, es importante asegurar que es posible hacer llamadas a una API Rest como la nuestra desde cualquier stack tecnológico. Preguntando a Chat GPT o bien mirando tutoriales en línea hay explicaciones para resolver este reto desde cualquier stack.Estructurar los JSON y hacer las llamadasDebes diseñar las llamadas a la API Verifacti según la documentación de las APIs, asegurando que cada llamada incluya:

• API key: Identifica al contribuyente, el entorno (test o producción) y la hacienda (Veri*Factu o Ticketbai).
• Cuerpo en formato JSON usando los ejemplos.

Escuchar la respuesta de la AEATEs necesario comprobar el estado de las peticiones realizadas, ya que las respuestas de la Administración no son síncronas y pueden tardar segundos o minutos. Esto te permitirá:

• Confirmar que la petición fue procesada correctamente.
• Detectar y corregir errores de la Administración a tiempo.

Se puede hacer:

1. A través de webhooks (preferible)
2. A través del endpoint de estado de registro (exige una llamada extra por cada petición)

Periodo de envíos a entorno de testEs aconsejable enviar facturas reales del software al entorno de test durante unos días o semanas para confirmar que la integración está bien hecha.Gestión de altas y bajas NIFsSe puede hacer manualmente o con la API de gestión de NIFs. Ver sección específica de preguntas frecuentes.Gestión de modelos de representaciónSe puede hacer manualmente o con la API de gestión de NIFs. Ver sección específica de preguntas frecuentes.

Tenemos una sección con ejemplos de llamadas y peticiones para todo tipo de facturas: Simplificada, Normal, Múltiples IVAs, A ciudadano extranjero, A empresa intracomunitaria, Exenta de IVA, Operación no sujeta, Con IGIC, Con IPSI, Suplidos y retención, Factura de abono, Factura de canje, Rectificativas, Rectificativas por sustitución, Rectificativas por diferencias, Recargo de equivalencia, Emitida por terceros, Emitida por destinatario, Anulación, Subsanación

Dispones de recursos para minimizar los bloqueos y consultas a soporte que te animamos a consultar:

• Documentación API sencilla y clara: Veri*Factu, Ticketbai y gestión NIFs
• Sección de ejemplos de llamadas y peticiones
• Sección de preguntas frecuentes hiper detallada
• Canal de YT con vídeos cortos

El 99% de las dudas se resuelven en estos materiales.

Las URLs de los endpoints no cambian, son las mismas para los entornos de test y de producción. Lo que determina qué entorno se usa es la API key que se utilice.Cada API key tiene un entorno asociado: test o producción.

• En entorno de test, la API key de la empresa empieza por vf_test_
• En entorno de producción, la API key de la empresa empieza por vf_prod_

Desde luego. Escríbenos a [email protected]. Lo más probable es que lo resolvamos con rapidez por email. Si hace falta haremos una llamada.

En la mayor parte de los casos la integración queda realizada con el trabajo de un solo desarrollador en uno a tres días a tiempo completo, y posteriormente unos días adicionales a tiempo parcial.

Para integrar con nosotros es preciso ser capaz de hacer llamadas a una API Rest. Muchos desarrolladores no se han enfrentado a este reto. De ser así, es importante asegurar que es posible hacer llamadas a una API Rest como la nuestra desde cualquier stack tecnológico. Preguntando a Chat GPT o bien mirando tutoriales en línea hay explicaciones para resolver este reto desde cualquier stack.

Sí. En la documentacion de las APIs encontrarás las colecciones de Postman para descargar.

• API Veri*Factu
• API Ticketbai
• API de gestión de NIFs

Posibles incidencias

La administración prevé la posibilidad de que se produzca algún incidente que impida el envío correcto de los registros de facturación a la administración.En concreto, la administración habla de las siguientes posibilidades:

• Corte de energía
• Caída de Internet
• Fallo informático
• Problemas de la propia API de la administración

La operativa del obligado tributario no debe verse interrumpida.En caso de producirse alguna de estas situaciones, la administración dispone que la incapacidad para hacer llegar los registros de facturación en tiempo real a la Administración Tributaria no debe ser obstáculo para la operativa y para la emisión normal de facturas por parte del contribuyente. Cuando una factura no ha podido ser enviada en el momento de su emisión, la Agencia Tributaria espera que esa factura sea enviada tan pronto como sea posible.Si bien no se especifica un plazo máximo para el envío de esas facturas, sí que hay énfasis en la obligación de cumplir con el envío en cuanto sea posible.Para situaciones en las cuales ha habido algún problema en torno al envío de una factura, la administración dispone de un campo de “incidencia” que espera que sea utilizado en estas situaciones.No emitir facturas sin QR ni registro de facturaciónSi bien la administración no pone pegas a la remisión tardía del registro de facturación, sí que establece que no debe en ningún caso entregarse una factura al cliente final sin que esta lleve el QR y sin que el registro de facturación (fichero XML) haya sido generado.Caída de la AEATEn caso de que la incidencia sea una caída de la API de la administración (algo que ya ha sucedido en entorno de pruebas en el pasado) Verifacti se encargará de reintentar los envíos hasta que la API de la AEAT vuelva a estar operativa. Los usuarios de Verifacti no deben preocuparse por lo tanto de esta eventualidad, que queda cubierta por nuestra API.Caída de Verifacti, internet o luzEn caso de que un problema impida la correcta comunicación del software de facturación usuario de Verifacti con nuestra API (caída de internet, corte de luz, caída de nuestra API) el software de facturación debe estar capacitado para reintentar las peticiones que no hayan podido completarse una vez se restablezca la normalidad.

La expectativa de la AEAT es que las facturas se remitan en tiempo real, no siendo posible enviar las facturas al final del día o de un periodo de tiempo sea cual sea.

Para un mismo NIF se pueden usar diferentes SIF (softwares de facturación).Si se emite dos facturas desde SIFs diferentes deben llevar dos series diferentes, cada una con su propia numeración.

No es necesario incluir las facturas antiguas anteriores del mismo periodo fiscal o de una misma serie.

En relación con el punto anterior, es importante aclarar que Veri*Factu permite la creación de facturas no consecutivas. En otras palabras, en el sistema Veri*Factu es posible crear facturas sin seguir un orden secuencial estricto, y estas facturas serán aceptadas sin errores. Sin embargo, la normativa de facturación exige la secuencialidad de las facturas, por lo que cumplir con Veri*Factu no exime del cumplimiento de dicha normativa.Por lo tanto, el reto de garantizar la secuencialidad de las facturas dentro de una misma serie es un reto ajeno a Veri*Factu, y que debe resolver el software de facturación.Este requisito de secuencialidad de las facturas dentro de una misma serie que establece la normativa de facturación (y que Veri*Factu ignora) no debe confundirse con el requisito de encadenamiento o trazabilidad que sí establece Veri*Factu, y que afecta a los registros de facturación (XMLs) que la API Verifacti se encarga de generar. Es Verifacti por lo tanto quien garantiza este requisito de trazabilidad de los XMLs.

Puedes usar tantas series como quieras dentro de un mismo NIF.

Cuando se emite una factura de tipo F1 es necesario identificar al destinatario. Aquí se distinguen dos casos:Cuando el destinatario es una persona física española (autónomo o no) o una entidad española con un NIF válido.

• En este caso hay que informar de los campos "nif" y "nombre" donde el "nombre" corresponde al nombre y apellidos para personas físicas y la razón social para entidades.
• Para personas físicas el nombre debe ser lo suficientemente parecido al que aparece en el DNI.

Cuando el destinatario no es una persona física española ni una entidad española con un NIF válido.

• En este caso hay que usar los campos "nombre" e "id_otro" para identificar al destinatario.
• Un caso concreto dentro de este caso general es el de empresas de la UE con un IVA VIES válido.

En caso de emitir una factura con algún error, será necesario emitir una rectificativa por sustitución.

Varifacti facilita varios recursos para ayudar en la validación de los datos de los destinatarios de las facturas, para así minimizar errores.En la llamada de Crear factura nueva existe un campo validar_destinatario que está por defecto a True.

• Si se incluye el campo nif validamos por defecto que está censado en la AEAT ya que si no lo está, la AEAT rechazará el envío. Esto requiere una llamada adicional por nuestro lado. Si estás seguro de que los NIFs de los destinatarios están censados, puedes desactivar esta validación poniendo este campo a false.
• De manera similar, si se incluye el campo id_otro con id_type igual a 02 validamos por defecto que el IVA esté en el censo VIES. Se puede desactivar esta validación poniendo este campo a false.

También hay endpoints específicos para usar de manera selectiva fuera del proceso de creación de factura. Estos endpoints requieren una suscripción de pago activada.

• El endpoint Validar NIF en la AEAT permite hacer la validación anterior a través de un endpoint.
• El endpoint Validar IVA en VIES permite validar que un número de IVA intracomunitario se encuentra en el censo VIES. Conviene saber que este endpoint utiliza una API de la EU que falla bastante.

Uno de los requisitos del sistema Veri*Factu al crear una factura nueva es incluir un desglose por tipo de IVA, que en la API de Veri*Factu se denomina líneas.Es importante aclarar que la administración no usa este desglose para obtener información sobre los productos o servicios vendidos. Su finalidad es exclusivamente reflejar diferentes tipos de IVA en aquellos casos en los que una misma factura incluya varios tipos de IVA.Por lo tanto, en situaciones en las que toda la factura tenga un único tipo de IVA, solo será necesaria una única línea.

La suma del desglose de una factura puede no coincidir exactamente con el total de la factura. Esta diferencia puede llegar a un máximo de varias decenas de euros. La administración no lo considerará un error.

Las facturas que incluyan retención por IRPF, como en pagos a autónomos, deben excluir el componente de IRPF al ser comunicadas a la Agencia Tributaria a través de Veri*Factu. Esto implica que el importe total de la factura en manos del destinatario final será diferente al importe total de la factura en Veri*Factu. Cuando se consulta una factura en la web de la AEAT (a través del QR) en la propia AEAT explica que los datos que ahí aparecen no incluyen las retenciones.

La administración establece que los suplidos no deben incluirse obligatoriamente en las facturas enviadas a través del sistema Veri*Factu. No obstante, pueden incluirse voluntariamente mediante una línea adicional con un IVA del 0%.

Veri*Factu sí contempla las facturas emitidas por terceros o destinatario (auto-facturas). En la API se hace usando el campo emitida_por_tercero_o_destinatario. Estas facturas se pueden y se deben enviar al igual que todas las demás.Algunas aclaraciones importantes respecto a este tipo de facturas:

• De cara a calcular costes de la API Verifacti, en este tipo de facturas el obligado tributario (sujeto pasivo de IVA) debe estar dado de alta como NIF, incluso aunque no sea usuario del software de facturación.
• En el JSON no aparecerán los datos del obligado tributario, porque esos datos vendrán comunicados a través de la API key de NIF
• En el caso de factura emitida por tercero, es necesario indicar quién es el tercero en los campos específicos nombre_tercero y nif_tercero

No existe una manera de consultar a Hacienda la última factura emitida. La última factura emitida debe obtenerse de la propia base de datos del software. Si es posible listar facturas a través del endpoint listar facturas que traslada la petición directamente a la AEAT, pero no puede hacer una llamada que devuelva solamente la última.

Sí, es recomendable guardar el QR por las siguientes razones:

1. Facilidad de reimpresión: Tener el QR guardado permite reimprimir el documento de manera rápida y sencilla en caso de pérdida o daño del original.
2. Verificación de autenticidad: El QR puede ser utilizado para verificar la autenticidad del documento en cualquier momento.
3. Cumplimiento normativo: Mantener el QR asegura que se cumplan las normativas de Veri*Factu y Ticketbai, ya que estos sistemas pueden requerir la presentación del QR en auditorías o revisiones.

Además, se sugiere almacenar el QR en un lugar seguro y accesible, como un archivo digital en la nube, para evitar su pérdida.

No debes incluir el identificador del SIF en tus llamadas a Verifacti porque:

1. Generación del XML: Verifacti se encarga de generar el XML necesario para la comunicación con la AEAT.
2. Incorporación del SIF: Es en este XML donde se incluye el identificador del SIF, asegurando que la información se envía correctamente a la AEAT.

Al dejar que Verifacti maneje este proceso, se minimizan errores y se garantiza el cumplimiento con las normativas de Veri*Factu y Ticketbai.

Sí es posible modificar y cancelar facturas

Para modificar o cancelar una factura ya generada es necesario realizar llamadas adicionales a la AEAT a través de registros de facturación adicionales.Los caminos posibles a seguir incluyen

• Facturas rectificativas con el endpoint Crear Factura Nueva (para la mayoría de los casos)
• Facturas de abono con el endpoint Crear Factura Nueva (para devolución total)
• Endpoint anular factura (para casos muy restringidos)
• Endpoint de subsanar factura (para casos muy restringidos)

Confusión con requisito de inalterabilidadEs común escuchar que con el sistema Veri*Factu las facturas no pueden modificarse. Esta percepción es errónea. La inalterabilidad exigida por Veri*Factu se refiere a los registros de facturación (XMLs generados por Verifacti), no a las facturas en sí mismas. Los registros de facturación son los XML que genera Verifacti a partir de las llamadas realizadas a la API. Por cada llamada realizada a la Agencia Tributaria hay un XML (registro de facturación) y estos no pueden modificarse a posteriori una vez creados.

Facturas rectificativas

• Siempre que quieras modificar cualquier aspecto de una factura (aceptada, parcialmente aceptada o rechazada) que suponga un cambio en datos con relevancia fiscal (como destinatario, importe, tipo impositivo, etc.), debes recurrir siempre a una factura rectificativa.
• Las facturas rectificativas son los tipos R1, R2, R3, R4 o R5
• Las rectificativas son facturas nuevas con serie diferente a la original, y con su propio QR.
• Estas facturas adicionales deben hacerse llegar al destinatario.
• Cuando haces una rectificativa (incluyendo la F3), haces referencia a la factura original. Sin embargo, la AEAT no parece que haga ningún tipo de comprobación de que la factura original haya sido enviada previamente ni nada por el estilo.

Puedes perfectamente hacer una rectificativa haciendo referencia a una factura que nunca se envió a través del sistema Veri * Factu y no te dará problema a nivel de la API de la AEAT.Factura de abono

• La única excepción es cuando emites una factura por un bien que posteriormente es devuelto en su totalidad. En ese caso, basta con emitir una factura “negativa” normal. Se trata de una factura ordinaria con importe total negativo y que puede ir en la misma serie.
• Se trataría de una factura normal F1 o F2.
• El hecho de que se puede emitir una F1 o F2 en negativo queda muy claro en los ejemplos de la AEAT, que se puede encontrar en el siguiente enlace.
• Estas facturas adicionales deben hacerse llegar al destinatario.
• Las facturas de abono no requieren serie propia, pueden ir en la misma serie que la factura original.

Estos endpoints existen en la API de Verifacti porque también existen en la API de la propia AEAT. Si bien la nomenclatura invita a usarlos para todo tipo de operaciones, la AEAT establece un uso muy restringido.Anulación

• Únicamente para facturas que nunca deberían de haberse emitido(emitidas por error).
• Importante: si se anula una factura, no se puede reutilizar ese número, ha de saltarse al siguiente porque de lo contrario Veri*Factu nos dirá que hay error de factura duplicada.

Subsanación

• Cuando el campo corregido no tenga ninguna implicación fiscal, quizás el campo descripción.

• En las facturas simplificadas (tipo F2) no se pueden añadir los datos del destinatario.
• Las facturas normales (tipo F1) sí llevan datos de destinatario.
• Se podría generar primero una simplificada y "convertirla" en una normal añadiendo los datos del destinatario

Muchos de nuestros usuarios se refieren a esto como "Factura de canje". En esta situación hay que emitir una factura nueva sustitutiva tipo F3. También se puede emitir una factura de abono para cancelar la original y luego emitir una factura normal con los datos del destinatario.

Las respuestas de la Administración no son síncronas y pueden tardar segundos o minutos. Una integración exitosa debe incluir un mecanismo para escuchar la respuesta de la AEAT a las peticiones realizadas para confirmar que no hay errores.Esto te permitirá:

• Confirmar que la petición fue procesada correctamente.
• Detectar y corregir errores de la Administración a tiempo.

Se puede hacer:

1. A través de webhooks (preferible)
2. A través del endpoint de estado de registro (exige una llamada extra por cada petición)

Ante una factura duplicada no es necesario emitir una rectificativa. La AEAT sencillamente la ignorará.

Para cumplir con TicketBAI, el software que envía los registros de facturación debe estar inscrito en el listado oficial de Software Garante. Es decir, si un software usa Verifacti para integrarse con las Haciendas Forales, Verifacti sí debe ser software garante (y lo es), pero el software que usa Verifacti no es necesario que sea software garante.Aunque la ley en sí no exige explícitamente que se utilice un software registrado, en la práctica es indispensable.Los archivos XML generados deben incluir datos identificativos del software conforme a su registro: nombre, versión, entidad desarrolladora y número de licencia TicketBAI.Este último se obtiene al completar el proceso de registro.Verifacti ya ha pasado por este proceso y es software garante. El proceso de registro en el País Vasco requiere que la empresa que va a enviar los registros (Verifacti) presente una memoria técnica que acredite el cumplimiento de los requisitos de TicketBAI. Asimismo, se debe entregar una declaración responsable que confirme el cumplimiento normativo y asuma compromisos ante posibles modificaciones legales que afecten al sistema.Puedes consultar los listados oficiales en los siguientes enlaces, en los que aparece Verifacti como software garante (Bilbabit SL):

• Listado de Software TicketBAI en Álava
• Listado de Software TicketBAI en Guipúzcoa
• Listado de Software Garante en Vizcaya

Firma y envío conforme a TicketBAI

Para cumplir con la normativa TicketBAI, el sistema de facturación debe generar un fichero XML por cada transacción, firmarlo digitalmente y remitirlo a la Hacienda Foral correspondiente.Nuestra API se encarga de generar el XML usando los datos proporcionados en la llamada a la API y de firmarlo conforme a la normativa.Cada factura se enlaza criptográficamente con la anterior, y la firma digital garantiza su integridad, evitando manipulaciones. Para ello, es necesario un certificado digital emitido por un proveedor de servicios de confianza cualificado.La legislación vigente admite el uso de varios tipos de certificados digitales para firmar facturas TicketBAI:

• Certificado de dispositivo: creado explícitamente para su uso en TicketBAI.
• Certificado representante de entidad: identifica a la persona física responsable de la persona jurídica.
• Certificado de sello de entidad:: no aparecen datos personales del representante, solo se identifica la empresa.
• Certificado de autónomo: creado explícitamente para su uso en TicketBAI.

En general, la decisión de qué certificado utilizar depende de diversos factores: naturaleza jurídica, software que se va a utilizar, escenario de facturación y características del certificado.¿Por qué elegir el certificado de dispositivo con Verifacti?

En Verifacti optamos por implementar el uso de certificados de dispositivo, ya que presentan numerosas ventajas frente a otras opciones:

• Uso exclusivo para TicketBAI: No permite realizar otros trámites ante la Hacienda Foral.
• Privacidad asegurada: El contribuyente no debe proporcionar su propio certificado personal.
• Simplicidad operativa: El mismo certificado puede utilizarse tanto para firmar como para enviar los ficheros XML.
• La API Verifacti integra un certificado de dispositivo emitido por un QTSP (Izenpe). Este debe estar previamente registrado y asociado al NIF del contribuyente ante la Hacienda Foral. Aunque Verifacti ofrece una opción gestionada para minimizar el esfuerzo técnico, también permite que el integrador utilice su propio certificado de dispositivo si así lo prefiere.

Registro del certificado de dispositivo

Para que el certificado de dispositivo pueda utilizarse en el envío de ficheros TicketBAI, debe estar vinculado al NIF del emisor de las facturas. El proceso varía ligeramente según la provincia:Para Álava y Vizcaya el registro se efectúa antes de enviar el primer registro de facturación. En caso de no hacerlo, Hacienda rechazará el envío e informará en el mensaje de error que la causa es que el certificado no esté registrado.Para Guipúzcoa el registro se efectúa después de enviar el primer registro de facturación.En ambos casos, el proceso de registro es muy sencillo y se realiza de manera telemática. Los pasos para hacerlo son los siguientes:

1. El contribuyente accede al portal web de la Hacienda Foral con su certificado digital personal.
2. Proporciona el número de serie del certificado de dispositivo de Verifacti (1f3647f642e9fae56807d91d6865a22a).

Puedes encontrar los enlaces a los portales de cada una de las Haciendas forales aquí:

• Registro de certificado de dispositivo en Araba
• Registro de certificado de dispositivo en Guipúzcoa
• Registro de certificado de dispositivo en Vizcaya

IMPORTANTE: Si el registro no se realiza, los ficheros TicketBAI serán rechazados por la Hacienda Foral.

¿Por qué existen dos APIs diferentes para integrar con Veri*Factu y con TicketBAI?Hemos decidido diseñar dos APIs diferenciadas, una para Veri*Factu y otra para TicketBAI, siguiendo en gran medida la estructura de las APIs oficiales de las administraciones.Esto aporta varias ventajas:

• Consistencia: los endpoints, campos y mensajes de error que presentamos a nuestros usuarios son prácticamente los mismos que en las APIs de las administraciones.
• Facilidad en consultas fiscales: esta similitud elimina interpretaciones o sesgos derivados de una API intermedia, lo que agiliza la comunicación con asesores y con las propias administraciones.

¿Qué implica esto a la hora de integrar?Es necesario integrar con dos APIs diferentes.Sin embargo, en la práctica, tras integrar con Veri*Factu, la integración posterior con TicketBAI suele requerir solo un 10%-20% adicional de esfuerzo. Esto se debe a que varias llamadas coinciden y, cuando no lo hacen, mantienen una estructura muy similar.Por ejemplo, al crear una factura será necesario contar con dos JSON diferentes, utilizando uno u otro según la API de destino.

En general, los términos VERI*FACTU o reglamento VERI*FACTU son formas abreviadas, coloquiales y significativas -aunque inexactas- de referirse al reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Este reglamento desarrolla parcialmente el artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT), introducido por la «ley antifraude» (Ley 11/2021, de 9 de julio), en lo que se refiere a sistemas y programas informáticos o electrónicos que soporten los procesos de facturación (denominados abreviadamente sistemas informáticos de facturación o SIF) de quienes desarrollen actividades económicas, es decir, de empresarios y profesionales.Este reglamento y el real decreto que lo aprueba imponen una serie de requisitos a los sistemas informáticos que se utilicen para expedir facturas, con el objetivo de evitar o dificultar y detectar que se pueda cometer fraude en ese proceso.Resumidamente, obligan a que esos SIF, en el momento de expedición de la factura, generen y guarden o remitan a la Agencia Tributaria un resumen de la factura -llamado registro de facturación- que lleva incorporada una serie de medidas de seguridad y control, como son la huella digital de sus datos, la inclusión de información del anterior registro generado (lo que permite verificar que no hay omisiones) y, en su caso, la firma electrónica del emisor del mismo. Asimismo, obligan a los SIF a que incluyan un código QR en la factura expedida, cuya lectura (por ejemplo, con la cámara de un teléfono móvil) permite a quien reciba dicha factura remitir fácilmente ciertos datos de la misma a la Agencia Tributaria, para su posible verificación.Por último, cabe señalar que el término VERI*FACTU con el que se suele conocer tanto a este reglamento como al real decreto que lo aprueba proviene del nombre de uno de los 2 tipos de SIF contemplados por el reglamento que se puede utilizar para cumplir con esta normativa y cuya característica más destacada es que remiten a la Agencia Tributaria un resumen estructurado de los datos de cada factura (denominado registro de facturación de alta) en el mismo momento de su expedición.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF).

Además de lo que se comenta al respecto en otras preguntas frecuentes relacionadas, la exigencia del cumplimiento de ciertos requisitos de seguridad y control a los sistemas informáticos de facturación (SIF) como una medida más de lucha contra el fraude fiscal se ha venido aplicando desde hace tiempo por muchas otras Administraciones tributarias, tanto de España (casos forales), como de otros países de la Unión Europea (Francia, Italia, Portugal, Alemania…) y del resto del mundo.En el caso que nos ocupa, tras estudiar numerosos sistemas ya implantados y sus respectivos tipos de requisitos, se ha optado por un enfoque en línea con las recomendaciones más recientes al respecto de la Organización para la Cooperación y el Desarrollo Económicos (OCDE). Además, se ha intentado no condicionar la forma de implementarlos, lo cual permite mayor libertad y flexibilidad a la hora de llevarlos a la práctica, favoreciendo la competencia de soluciones, bien sean basadas en software, en hardware o mixtas. Así se reducen costes y se permite elegir el SIF que mejor se adapte a las circunstancias y necesidades de cada empresario o profesional, facilitando, en definitiva, su adopción.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF).

En primer lugar, con la utilización de sistemas informáticos de facturación adaptados al reglamento se evitará -o dificultará y detectará- que se puedan llevar a cabo prácticas fraudulentas en ese proceso, tales como la omisión de facturas o la alteración de las facturas de venta una vez expedidas. Esto tiene dos grandes consecuencias:Por un lado, incidirá directamente en una reducción del fraude cometido, lo que traerá consigo una mayor justicia fiscal que redundará en el bien de toda la ciudadanía.Por otro lado, impedirá o reducirá significativamente la competencia desleal de la que se aprovechan quienes defraudan frente a quienes cumplen con sus obligaciones tributarias.Adicionalmente, la adopción de este tipo de requisitos y formatos contribuirá a estandarizar y modernizar los sistemas informáticos empresariales, avanzando en la digitalización de los empresarios y profesionales. Como resultado de esto se consiguen dos efectos:Se facilitan y fomentan las relaciones entre los propios empresarios y profesionales, y de estos con sus representantes fiscales, al utilizar unos formatos de información de facturación comunes, favoreciendo su intercambio y reduciendo costes, cuestiones que tienen un impacto beneficioso en la actividad comercial.Se concreta y simplifica la comunicación de información a la Administración tributaria, facilitándose el cumplimiento tributario.Asimismo, este reglamento pretende ofrecer a quienes reciban facturas (incluyendo facturas simplificadas) una forma fácil e inmediata de remitir ciertos datos de las mismas a la Agencia Tributaria, para su posible comprobación. Esto contribuye a una mayor transparencia en los negocios, así como a desarrollar la conciencia fiscal y la cultura del cumplimiento tributario.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.Apartado I del preámbulo del Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF).

El artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT), obliga a los productores, comercializadores y usuarios de sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas a que dichos sistemas informáticos garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Para ello, permite que se establezcan ciertas especificaciones técnicas a cumplir, así como su certificación y que usen formatos estándar de manera que sus registros sean legibles.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.

El artículo 201 bis de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT), prevé dos tipos de sanciones, ambas graves:A la fabricación, producción y comercialización de sistemas informáticos que no cumplan con lo dispuesto en el artículo 29.2.j de la LGT y su normativa de desarrollo (reglamento, orden ministerial y documentación relacionada de la sede electrónica de la Agencia Tributaria).La cuantía estipulada es de 150.000 euros fijos por cada ejercicio económico en el que se hayan producido ventas de este tipo de sistemas informáticos y por cada tipo distinto de estos que sea objeto de la infracción.Por otro lado, cuando no se certifiquen dichos sistemas informáticos estando obligados a ello, se sancionará con 1.000 euros por sistema informático comercializado sin dicha certificación.A la tenencia de sistemas informáticos que no se ajusten a lo establecido en el artículo 29.2.j de la LGT, cuando los mismos no estén debidamente certificados teniendo que estarlo por disposición reglamentaria o cuando se hayan alterado o modificado los dispositivos certificados. El importe es de 50.000 euros por cada ejercicio.Normativa/Doctrina:Artículo 201 bis de la Ley 58/2003, de 17 de diciembre, General Tributaria.

Solo a aquellos que se utilicen para expedir facturas (incluyendo las facturas simplificadas), es decir, a los sistemas informáticos de facturación (SIF), siempre y cuando sean utilizados por obligados a expedir facturas (completas o simplificadas, tanto a otros empresarios como a consumidores finales) a quienes les aplique el reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre: ver el apartado 2 de la pregunta frecuente "¿A quién afecta el reglamento que establece los requisitos de los sistemas informáticos de facturación?" y su “regla de los 4 «NO»” de Cuestiones generales: ámbitos de aplicación.Por el contrario, no se aplicará a otros sistemas informáticos que se utilicen para emitir otro tipo de documentos justificativos de entrega de bienes o prestación de servicios.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.Artículos 1.1 y 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Dado que el reglamento que establece los requisitos de los sistemas informáticos de facturación se aplica a los sistemas informáticos de facturación (SIF), entendiéndose por SIF los utilizados para expedir facturas, los únicos documentos afectados por este reglamento son las FACTURAS, tanto las «completas u ordinarias» como las simplificadas, no afectando a ningún otro tipo de documentos justificativos de entrega de bienes o prestación de servicios.Las facturas expedidas con estos SIF deberán incluir una representación de cierta información de las mismas mediante un código «QR» tributario. Además, estos SIF deberán generar -y firmar y guardar o, en su caso, remitir- los correspondientes registros de facturación de las facturas expedidas.Normativa/Doctrina:Artículos 1.1 y 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículos 6.5 y 7.5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, introducidos por la disposición final primera uno y dos del Real Decreto 1007/2023, de 5 de diciembre.

Además de las menciones que deben tener actualmente las facturas, sean ordinarias o simplificadas, aquellas que sean expedidas con sistemas informáticos de facturación (SIF) a los que se refiere el Real Decreto 1007/2023, de 5 de diciembre, deberán incorporar un código «QR» tributario que facilite la comunicación a la Agencia Tributaria de ciertos datos de la misma. Y si el SIF que las ha expedido está funcionando en la modalidad VERI*FACTU, deberá incluirse también la frase «Factura verificable en la sede electrónica de la AEAT» o VERI*FACTU.Normativa/Doctrina:Artículos 6.5 y 7.5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, introducidos por los apartados uno y dos de la disposición final primera del Real Decreto 1007/2023, de 5 de diciembre.

La introducción y edición temporal de datos, visualización previa, etc. de facturas no está prohibida ni por el reglamento que establece los requisitos de los sistemas informáticos de facturación ni por el reglamento de obligaciones de facturación, si bien hasta no estar terminada la factura, esta no podrá ser expedida con su correspondiente código «QR» tributario. Por ello tanto los borradores de factura como las facturas proforma no llevan ningún código «QR» tributario. La emisión de facturas - o facturas simplificadas- proforma o sin validez fiscal, está permitida siempre y cuando se sustituyan finalmente por la factura o factura simplificada oficial expedida y esta se entregue al cliente.Cuando una factura sea definitivamente emitida (es decir, en general, cuando se haya incorporado a ella el QR y generado el correspondiente registro de facturación de alta, firmado o remitido a la Sede electrónica de la Agencia Tributaria), ya no podrá ser considerada un borrador y su alteración, en los elementos informativos que integran el “registro de facturación de alta”, no estará permitida a menos que se realice por medio de nuevos registros de facturación, como indica el tercer párrafo del artículo 8.2.a del reglamento aprobado por el RD 1007/2023.A efectos informáticos, el sistema de generación de facturas pro-forma o sin validez fiscal, debe estar vinculado indefectiblemente al sistema de emisión de facturas formando una unidad. Conviene, a efectos de control interno, que se conserve registro de las prefacturas o facturas proforma elaboradas.Por ello, no sería legal y sería susceptible de sanción, el uso de sistemas que generen documentos preparatorios de facturas o de facturas simplificadas, sin que el sistema informático mismo disponga de elementos de control para la conservación de tales documentos preparatorios de forma debidamente vinculada a las facturas o a los registros de facturación que finalmente se emitan o, en defecto de factura, de forma que queden registrados y conservados en el sistema.Normativa/Doctrina:Artículos 1.1 y 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículos 6.5 y 7.5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, introducidos por la disposición final primera uno y dos del Real Decreto 1007/2023, de 5 de diciembre.

Resumidamente, se considera sistema informático de facturación (SIF) al conjunto de hardware y software utilizado para expedir facturas que admita la entrada de información de facturación por cualquier vía, conserve esta información y la procese para generar otros productos derivados, con independencia de dónde se realice este proceso.De forma más extensa, un sistema informático de facturación (SIF) es el conjunto de hardware y software utilizado para expedir facturas mediante la realización de las siguientes acciones:Admitir la entrada de información de facturación por cualquier método. Como ejemplos típicos:­Introducir en el SIF los datos de las facturas directamente de forma manual. ­Importar en el SIF los datos necesarios para expedir las facturas, cuando estos han sido capturados en otros sistemas. ­­Recibir en el SIF (en línea o por lotes) mediante procesos automatizados los datos necesarios para expedir las facturas, cuando estos han sido capturados en otros sistemas.­Conservar la información de facturación, dentro o fuera del SIF.Con ello se quiere decir que el producto obtenido, una vez expedida -y, típicamente, impresa- la factura (a partir de la información del apartado anterior), no se descarta o elimina, sino que se almacena y guarda, manteniéndose en el tiempo.Procesar la información de facturaciónmediante cualquier procedimiento para producir otros resultados derivados, independientemente de dónde se realice dicho procesamiento (en el propio SIF o en otro sistema informático que tenga acceso a dicha información).Es decir, implica que la información capturada y guardada electrónicamente de las facturas expedidas sea procesada con otras finalidades, obteniendo nuevos resultados derivados de ella, como puede ser la confección de los libros registros de IVA, los libros registros de IRPF, la contabilidad o cualquier otro resultado que se utilice para el cumplimiento de obligaciones tributarias.Normativa/Doctrina:Artículo 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Hay 2 tipos de colectivos afectados:Los productores y comercializadores de sistemas informáticos de facturación (SIF) en las cuestiones relativas a sus respectivas actividades de producción y comercialización de los sistemas informáticos destinados a ser utilizados por el colectivo que se menciona a continuación en el siguiente apartado.Aquellos empresarios y profesionales -personas físicas o jurídicas- que, estando establecidos en territorio español, expidan facturas (ver NOTA 1 aclaratoria al final de esta respuesta), siempre y cuando cumplan las 4 condiciones siguientes (lo que podría denominarse la “regla de los 4 «NO»”):Que NO facturen exclusivamente de forma manual (sin ayuda de SIF). Dicho de otro modo, que utilicen algún SIF para expedir facturas.Que NO estén adscritos, de forma obligatoria o voluntaria, a las exigencias del conocido como Suministro Inmediato de Información o SII. Ver NOTA 2 aclaratoria al final de esta respuesta.Que NO tengan su domicilio fiscal en los Territorios Históricos de la Comunidad Autónoma del País Vasco o de la Comunidad Foral de Navarra. Ver más aclaraciones en la NOTA 3 al final de esta respuesta.Que NO dispongan de alguna resolución en vigor de no aplicación que les exima de cumplir con el RRSIF, aprobado por el Real Decreto 1007/2023, de 5 de diciembre. Ver NOTA 4 aclaratoria al final de esta respuesta.NOTA 1 al apartado 2 de esta respuesta:Como se puede observar, en este segundo apartado se habla en todo momento de quienes expidan FACTURAS -incluidas las facturas simplificadas- cualquiera que sea el motivo para ello (normalmente por estar obligados según el Real Decreto 1619/2012, de 30 de noviembre, que aprueba el Reglamento por el que se regulan las obligaciones de facturación, ROF). Así pues, a ese respecto, se excluyen todas aquellas operaciones que no se documenten con factura porque no haya obligación de expedir factura según dichos RD 1619/2012 y ROF (incluyendo las autorizaciones “especiales” concedidas que pudiera haber en este sentido).Por lo tanto, el hecho de expedir (o no) factura es clave porque, por definición (artículo 1.2 del RRSIF) el RRSIF no cambia las obligaciones sustanciales de facturación. Un SIF -cuyo funcionamiento es lo que el reglamento regula- es, en esencia, un sistema informático utilizado para expedir FACTURAS. Así que el RRSIF no aplica a sistemas informáticos que no expidan facturas.NOTA 2 a la letra b) del apartado 2 de esta respuesta:El SII se refiere a la llevanza en la sede electrónica de la Agencia Tributaria de los libros registros de IVA en los términos establecidos en el apartado 6 del artículo 62 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre.Si un obligado tributario está acogido al SII deberá usar un Sistema que le permita cumplir con las exigencias informativas del SII.NOTA 3 a la letra c) del apartado 2 de esta respuesta:La letra c) del apartado 2 se refiere a que la competencia de exacción tributaria según el domicilio de quien expide la factura NO sea propia de los Territorios Históricos de la Comunidad Autónoma del País Vasco o de la Comunidad Foral de Navarra, de acuerdo con las normas del Concierto y Convenio Económicos. O sea, que NO sean obligados tributarios que realicen actividades económicas (ya sean personas físicas o jurídicas) que se encuentren sujetas por dichas actividades a la normativa foral en la Imposición Directa, tanto en el caso de los 3 territorios históricos de la Comunidad Autónoma del País Vasco (Ley 12/2002, de 23 de mayo, por la que se aprueba el Concierto Económico con la Comunidad Autónoma del País Vasco, y, en concreto, lo establecido en los artículos 6 y 14 de dicho texto, respectivamente, para IRPF e Impuesto de Sociedades), como en el de la Comunidad Foral de Navarra (Ley 28/1990, de 26 de diciembre, por la que se aprueba el Convenio Económico entre el Estado y la Comunidad Foral de Navarra, y, en concreto, según lo establecido en los artículos 9 y 18 de dicho texto, respectivamente para IRPF e Impuesto de Sociedades). De acuerdo con la mencionada normativa existente al respecto y según las condiciones de aplicación que se dan en el RRSIF, esa circunstancia se determina con base en el domicilio fiscal de los mismos.Por último, para que no haya dudas en lo referente a este aspecto, se confirma que quedan sujetos a la aplicación del reglamento (al menos por lo que se refiere a este criterio) los obligados a expedir facturas radicados en Canarias, Ceuta o Melilla, entendiendo que las referencias al Impuesto sobre el Valor Añadido (IVA) deben considerarse hechas al Impuesto General Indirecto Canario (IGIC) e Impuesto sobre la Producción, los Servicios y la Importación (IPSI), respectivamente.NOTA 4 a la letra d) del apartado 2 de esta respuesta:Se refiere a la posibilidad prevista específicamente en el artículo 5 del RRSIF.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT).Artículos 1, 3, 4 y 5 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales (RRSIF), y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Real Decreto 1619/2012, de 30 de noviembre, que aprueba el reglamento por el que se regulan las obligaciones de facturación (ROF).Artículo 62.6 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre.

Esto varía según el colectivo afectado (ver pregunta frecuente "¿A quién afecta el reglamento que establece los requisitos de los sistemas informáticos de facturación?" de Cuestiones generales: ámbitos de aplicación) de que se trate:Los empresarios y profesionales que expidan facturas a los que les afecte el reglamento deberán tener operativos sus sistemas informáticos de facturación (SIF), adaptados a las características y requisitos que se establecen en él y en su normativa de desarrollo, antes del 1 de enero de 2026, si tributan en el Impuesto sobre Sociedades y 1 de julio de 2026, para el resto.Los productores y comercializadores de aquellos SIF a los que les sea de aplicación el reglamento, en relación con sus actividades de producción y comercialización de dichos SIF, deberán ofrecer sus productos adaptados totalmente al reglamento en el plazo máximo de nueve meses desde la entrada en vigor de la orden ministerial que desarrolle las especificaciones técnicas de los requisitos impuestos a los SIF. No obstante, en relación con SIF incluidos en los contratos de mantenimiento de carácter plurianual contratados antes de este último plazo, deberán estar adaptados al contenido del reglamento con anterioridad con anterioridad a las fechas indicadas en el apartado anterior.Naturalmente, si los obligados disponen de SIF adaptados con anterioridad a esos plazos, podrán comenzar a usarlos y la Agencia Tributaria dispondrá de medios para facilitar, en su caso, la remisión de registros de facturación de los SIF «VERI*FACTU» con antelación a dicha fecha.Normativa/Doctrina:Disposición final cuarta del Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), modificada por el Real Decreto Real Decreto 254/2025, de 1 de abril.

No, siempre y cuando no se expidan facturas o estas se expidan TODAS a mano, es decir, sin utilizar para ello un sistema informático de facturación (SIF).Por el contrario, si en algún momento se expidiera alguna factura -por el motivo que sea- y para ello se utilizara un SIF, entonces sí que sería de aplicación el RRSIF (siempre que se cumpla también con el resto de condiciones indicadas en el apartado 2 de la pregunta frecuente "¿A quién afecta el reglamento que establece los requisitos de los sistemas informáticos de facturación?" (regla de los 4 «NO») de Cuestiones generales: ámbitos de aplicación.Es importante recordar que el RRSIF solo aplica a los SIF y estos, por definición (artículo 1.2 del RRSIF), solo se consideran tales si son utilizados para expedir lo que -según el ROF- tenga la consideración de FACTURA, incluida la factura simplificada (artículo 1.2 del RRSIF) pero no otros documentos similares o “equivalentes” también justificativos de operaciones.Normativa/Doctrina:Artículo 2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT).Artículos 1, 3, 4 y 5 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Real Decreto 1619/2012, de 30 de noviembre, que aprueba el reglamento por el que se regulan las obligaciones de facturación (ROF).

No se incluyen dentro del ámbito subjetivo del Reglamento SIF aprobado por el RD 1007/2023 aquellas personas que realicen actividades económicas (ya sean personas físicas o jurídicas) que se encuentren sujetas por dichas actividades a la normativa foral en la imposición directa.Para determinar qué empresarios y profesionales, se sujetan a normativa foral se seguirán las normas de la Ley 12/2002, de 23 de mayo, por la que se aprueba el Concierto Económico con la Comunidad Autónoma del País Vasco, y, en concreto, lo establecido en los artículos 6 y 14 de dicho texto, respectivamente, para IRPF e Impuesto de Sociedades.En los territorios históricos de Guipúzcoa, Vizcaya y Álava se está aplicando un sistema, conocido como “TicketBAI”, en sus distintas modalidades de contenido similar a la modalidad VERI*FACTU del Reglamento de Sistemas Informáticos de Facturación.Por ejemplo, en el caso de que se relacionen comercialmente una empresa con domicilio foral y otra con domicilio en territorio común (resto de España), los SIF utilizados por la primera para expedir sus facturas estarán sometidos a las obligaciones que establece su correspondiente Hacienda Foral, mientras que los SIF de la segunda estarían sujetos al RRSIF.Normativa/Doctrina:Artículo 1.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Con carácter general, en la Comunidad Foral de Navarra no será aplicable el RD 1007/2023, de 5 de diciembre, que aprueba el Reglamento regulador de los sistemas informáticos de facturación, cuando los empresarios y profesionales, se sujeten a normativa foral de acuerdo con las normas de la Ley 28/1990, de 26 de diciembre, por la que se aprueba el Convenio Económico entre el Estado y la Comunidad Foral de Navarra, y, en concreto, de acuerdo con lo establecido en los artículos 9 y 18 de dicho texto, respectivamente para IRPF e Impuesto de Sociedades.

Sí, los contribuyentes con domicilio fiscal en Canarias, Ceuta y Melilla, se encuentran comprendidos dentro del ámbito subjetivo de aplicación del Reglamento SIF aprobado por el Real Decreto 1007/2023 y, consiguientemente, les son de aplicación dichas normas y las de su desarrollo por medio de Orden Ministerial.De acuerdo con el artículo 1.3, las referencias que realiza el Reglamento SIF a la normativa del Impuesto sobre el Valor Añadido, se considerarán también efectuadas a la normativa del Impuesto General Indirecto Canario y a la del Impuesto sobre la Producción, los Servicios e Importación en Ceuta y Melilla.

Sí, siempre que cumpla también con el resto de condiciones indicadas en el apartado 2 de la pregunta frecuente "¿A quién afecta el reglamento que establece los requisitos de los sistemas informáticos de facturación?" (regla de los 4 «NO») de Cuestiones generales: ámbitos de aplicación.El Real Decreto 1007/2023, de 5 de diciembre, y el reglamento de requisitos de los sistemas informáticos de facturación (RRSIF) que aprueba son aplicables en todo el territorio español no foral, teniendo en cuenta las especialidades previstas en su normativa específica para Canarias, Ceuta y Melilla, entendiendo que las referencias realizadas a la normativa del Impuesto sobre el Valor Añadido (IVA) deben considerarse también efectuadas a la normativa del Impuesto General Indirecto Canario (IGIC) y a la del Impuesto sobre la Producción, los Servicios y la Importación (IPSI), respectivamente.Normativa/Doctrina:Artículo 1.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Por lo que se refiere a IRPF, es preciso determinar si el arrendamiento realizado supone la realización de actividad económica o por el contrario es fuente de rendimientos del capital inmobiliario. Para la consideración como actividad económica se exige que se utilice, al menos una persona empleada con contrato laboral y a jornada completa.Por lo tanto, si la actividad no tiene consideración empresarial, no será actividad económica en el sentido del artículo 3.1.b RRSIF, y en ese caso el arrendador no deberá adaptarse porque no se está desarrollando actividad económica.No obstante, si se trata de un alquiler de un apartamento turístico y se ofrecen servicios complementarios, propios de la industria hotelera, los rendimientos que obtiene por el alquiler son rendimientos de actividades económicas, y, por lo tanto, las facturas que se emitan en este contexto deben entenderse incluidas en el ámbito objetivo del Real Decreto 1007/2023, que aprueba el Reglamento que regula los Sistemas Informáticos de Facturación (RRSIF).Normativa/Doctrina:Artículo 3.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Se trata de normativas diferentes con obligaciones diferenciadas. El SII consiste en la llevanza de los libros registro de IVA (facturas emitidas, facturas recibidas, bienes de inversión…) a través de la sede electrónica de la Agencia Tributaria, lo que implica obligaciones de comunicación electrónica a la Agencia Tributaria de una amplia información relacionada con el IVA de las facturas emitidas y recibidas en un determinado plazo de tiempo. Por su parte, el reglamento que establece los requisitos de los sistemas informáticos de facturación obliga a que los SIF registren, con determinadas medidas de seguridad y control, cierta información solo de las facturas expedidas, pudiendo remitirse opcionalmente a la Agencia Tributaria.El ámbito subjetivo de ambos proyectos es excluyente, es decir, quienes cumplan con el SII no han de cumplir con el reglamento que establece los requisitos de los sistemas informáticos de facturación y viceversa.Por lo tanto, conforme al artículo 3.3 del Reglamento aprobado por RD 1007/2023, este Reglamento NO obliga a los obligados tributarios sometidos al Suministro Inmediato de Información (SII) en relación con sus propias facturas.Normativa/Doctrina:Artículo 3.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Orden HFP/417/2017, de 12 de mayo, por la que se regulan las especificaciones normativas y técnicas que desarrollan la llevanza de los Libros registro del Impuesto sobre el Valor Añadido a través de la Sede electrónica de la Agencia Estatal de Administración Tributaria establecida en el artículo 62.6 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre, y se modifica otra normativa tributaria.

Sí, mediante la opción prevista en la declaración censal modelo 036, un contribuyente que se haya inscrito en REDEME o que directamente haya optado voluntariamente al SII no estaría obligado a cumplir las especificaciones del RD 1007/2023, sin perjuicio de asumir desde el periodo de liquidación inmediato siguiente el conjunto de las obligaciones que se desprenden del artículo 62.6 del RIVA sobre su facturación emitida y recibida.Normativa/Doctrina:Artículo 3.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

No con carácter general, ya que los obligados a este régimen, no están obligados a expedir factura salvo determinadas excepciones.Sin embargo, la respuesta es la contraria, siempre que utilicen un sistema informático de facturación, cuando emitan otras facturas de obligada expedición por las entregas de inmuebles a que se refiere el segundo párrafo del apartado uno del artículo 129 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, según indica el último párrafo del artículo 3.3 del ROF, y siempre que cumplan también con el resto de condiciones indicadas en el apartado 2 de la pregunta frecuente "¿A quién afecta el reglamento que establece los requisitos de los sistemas informáticos de facturación?" (regla de los 4 «NO») de Cuestiones generales: ámbitos de aplicación. Para estas operaciones excepcionales podrán utilizar el sistema facilitado para ello por la AEAT en su sede electrónica, de acuerdo con el artículo 7.b del RRSIF.De igual manera también estará obligado a cumplir el RRSIF cuando utilice un sistema informático de facturación para la expedición voluntaria de facturas en relación a las operaciones exceptuadas de la obligación de expedir facturar.Normativa/Doctrina:Artículos 3.3 y 16.1 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre.Artículo 129.1 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido.

No con carácter general, ya que los obligados a este régimen no están obligados a expedir factura, salvo determinadas excepciones.No obstante, estará obligado a cumplir el RRSIF cuando utilice un sistema informático de facturación para la expedición voluntaria de facturas en relación a las operaciones exceptuadas de la obligación de expedir facturar.También, deberá cumplir las obligaciones del reglamento que establece los requisitos de los sistemas informáticos de facturación en el caso de que expida facturas, siempre que cumpla también con el resto de condiciones indicadas (“regla de los 4 «NO»”). Según la normativa de facturación, en el régimen de recargo de equivalencia se deben expedir facturas por realizar determinadas operaciones:

• Cuando efectúe entregas de inmuebles sujetas y no exentas al IVA.
• Cuando tribute en IROF en estimación directa.
• Cuando el cliente sea un empresario o profesional o una Administración Pública.
• Cuando el destinatario lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.
• Cuando se le exija para determinadas operaciones de comercio exterior.

Para estas operaciones excepcionales podrán utilizar el sistema facilitado para ello por la AEAT en su sede electrónica, de acuerdo con el artículo 7.b del RRSIF.Normativa/Doctrina:Artículo 3.1.b del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

No con carácter general, ya que los obligados a este régimen no están obligados a expedir factura, salvo determinadas excepciones.No obstante, estará obligado a cumplir el RRSIF cuando utilice un sistema informático de facturación para la expedición voluntaria de facturas en relación a las operaciones exceptuadas de la obligación de expedir facturar.También, deberá cumplir las obligaciones del RRSIF en el caso de que expida facturas, siempre que cumpla también con el resto de condiciones indicadas (“regla de los 4 «NO»”). Según la normativa de facturación, en el régimen simplificado de IVA se deben expedir facturas por realizar determinadas operaciones:

• Cuando la determinación de las cuotas devengadas se efectúe en atención al volumen de ingresos,
• Cuando efectúe la venta de activos fijos,
• Cuando el cliente sea un empresario o profesional o una Administración Pública.
• Cuando el destinatario lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.
• Cuando se le exija para determinadas operaciones de comercio exterior.

Para estas operaciones excepcionales podrán utilizar el sistema facilitado para ello por la AEAT en su sede electrónica, de acuerdo con el artículo 7.b del RRSIF.Para mayor detalle puede consultarseNormativa/Doctrina:Artículo 3.1.c del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre.Artículo 123.Uno.B.3.º de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido.

Los contribuyentes acogidos a los regímenes de la agricultura, ganadería y pesca, simplificado y de recargo de equivalencia, están, en general, excluidos de la obligación de emitir factura o factura simplificada. Si bien, esa regla tiene excepciones recogidas en los artículos 3.1 y 26 del Reglamento de Obligaciones de Facturación (RD 1619/2012). La mencionada normativa en relación a la obligatoriedad de emitir factura o factura simplificada es presupuesto de la normativa contenida en el Reglamento que regula los Sistemas Informáticos de Facturación (RRSIF), aprobado por RD 1007/2023, de 5 de diciembre.No obstante, la práctica empresarial, a menudo exige la emisión de justificantes de venta que pueden, o no, revestir la forma de facturas simplificadas y que, estrictamente hablando, no están prohibidas por la norma y pueden emitirse voluntariamente, ya que la normativa se limita a no exigir la obligación de facturar en determinados supuestos. Tales documentos justificativos, en la medida que no sean facturas completas o simplificadas, que sean emitidos en el contexto de las operaciones que quedan excluidas de la obligación de facturación, no estarán sometidas al RRSIF.Por consiguiente, debe entenderse que cualquiera que sea la razón por la que un empresario emita facturas o facturas simplificadas mediante un Sistema Informático de Facturación (SIF), deberá adoptar sus sistemas a la normativa derivada del RD 1007/23 y su OM de desarrollo.Por el contrario, si en aplicación de la normativa de facturación (que incluye también el artículo 26 ROF), no se emiten facturas en sentido propio, no será de aplicación el RRSIF.

Sí, porque con independencia de su tributación en el IVA, a efectos del IRPF determina su rendimiento de actividad económica mediante la aplicación del método de estimación directa.El artículo 26 ROF establece que los contribuyentes del IRPF que obtengan rendimientos de actividades económicas estarán obligados a expedir factura, cuando dichos rendimientos se determinen por el método de estimación directa, con independencia del régimen a que estén acogidos en el IVA.En consecuencia, el RRSIF se aplicará a los sistemas informáticos de facturación empleados por los titulares de oficina de farmacia o a cualquier otro contribuyente del IRPF que determine su rendimiento de actividad económica mediante estimación directa, con independencia del régimen de IVA.

Las facturas simplificadas están sometidas al RRSIF y, en el caso de sistemas VERI*FACTU deben comunicarse a la AEAT. Lo anterior es independiente de que al final del día se genere una factura o extracto recapitulativo como resumen, con el propósito de asentar en un solo apunte contable las ventas del día o de gestionar el negocio.En el caso de que se trate de operaciones que correspondan a regímenes especiales de IVA, simplificado, de recargo de equivalencia o de agricultura, nos remitimos a las preguntas específicamente dedicadas a estos.Normativa/Doctrina:• Artículo 2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre

Sí, la forma convencional o virtual por medio de la cual se oferten o entreguen los bienes o se presten los servicios es indiferente para la obligatoriedad de la aplicación de la normativa incluida en el reglamento de requisitos de los sistemas informáticos de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y su normativa de desarrollo.La venta online, en algunos casos tiene normativa específica cuando se utilicen regímenes europeos de ventanilla única, que pueden dar lugar a codificaciones específicas en el registro de alta de facturación, pero tales especialidades no excluyen del cumplimiento de las obligaciones del RRSIF.Normativa/Doctrina:• Artículos 2 y 3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

En el caso de que la facturación se produzca de forma manual, por talonarios o escribiendo sobre los mismos a mano o a máquina, no le afectaría el RRSIF porque no utiliza NINGÚN sistema informático de facturación (SIF) para expedir sus facturas.Una alternativa sencilla y adecuada que puede servirle para sustituir los sistemas manuales es utilizar la aplicación básica de facturación que ofrecerá gratuitamente la Agencia Tributaria en su sede electrónica, siempre y cuando sus funcionalidades y condiciones de uso se ajusten a las necesidades de quien la vaya a utilizar.Normativa/Doctrina:Artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.Artículo 1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

El reglamento no le afectará si los procesadores de texto o las hojas de cálculo se utilizan exclusivamente para:

• Introducir los datos de las facturas.
• Expedir e imprimir las facturas.
• Conservar la información de facturación.

Por el contrario, sí estará sujeto al reglamento y se considerará un sistema informático de facturación si, además de las funciones anteriores, se utiliza para procesar la información de facturación contenida en el programa para generar directamente los libros registros de IVA, los libros registro de IRPF, la contabilidad, o cualquier otro resultado que se utilice para el cumplimiento voluntario de obligaciones tributarias.Por ejemplo, si un usuario utiliza una hoja de cálculo Excel para generar simples listados de facturas emitidas, incluyendo sumatorios o el uso de otras reglas de cálculo, no le afectará el Reglamento. Pero si la utiliza programando una Macro, para generar el libro registro de facturas expedidas, su hoja de cálculo sí se considerará un sistema informático de facturación y, por lo tanto, deberá cumplir con los requisitos del Reglamento.Comprobación por parte de la AEATLa Agencia Tributaria podrá verificar si los procesadores de texto o las hojas de cálculo utilizadas para la emisión de facturas cumplen los criterios de un sistema informático de facturación en función de las capacidades y herramientas que utilicen.Alternativa gratuita para pequeños empresarios y profesionalesLe recordamos que la AEAT ofrecerá gratuitamente una aplicación básica de facturación, que podrá utilizar siempre y cuando sus funcionalidades y condiciones de uso se ajusten a sus necesidades.

No, si de acuerdo con el Reglamento por el que se regulan las obligaciones de facturación, aprobado Real Decreto 1619/2012, de 30 de noviembre, o bien por una autorización de facturación del artículo 3.1.d de ese mismo Reglamento no concurriera obligación de facturación, tampoco será aplicable la normativa del Reglamento de Sistemas Informáticos de Facturación.

La inclusión del código QR y la mención VERI*FACTU es de aplicación a los sistemas informáticos a que se refiere el artículo 7 del Reglamento aprobado por el Real Decreto 1007/2023. Como quiera que de dicho ámbito subjetivo se excluye a los obligados al SII, dichos requisitos SOLO se aplican a las operaciones y los obligados del artículo 3. Los obligados al SII, a todos los efectos, no quedan afectados por el RD 1007/2023.Normativa/Doctrina:• Artículo 3.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Apartado 5 del artículo 6 y apartado 5 del artículo 7 del Reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

Sí, de hecho, todas las obligaciones del Real Decreto 1007/2023, por lo que se refiere a los usuarios, serán de aplicación en las fechas propuestas en la disposición final cuarta del RD 1007/2023, redacción dada por el Real Decreto 254/2025, ya que la normativa modificada del Reglamento de obligaciones de facturación (ROF) RD 1619/2012, depende de la que se regula en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF).Las obligaciones que corresponden a los productores y comercializadores (producir y vender programas de software adaptados) entrarán en vigor a los 9 meses de la publicación de la OM técnica.Naturalmente, si los obligados disponen de sistemas adaptados con anterioridad, podrán comenzar a usarlos y la Agencia dispondrá de medios para facilitar el envío de VERI*FACTU con antelación.Normativa/Doctrina:Disposición Final Cuarta del Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), modificada por el Real Decreto 254/2025.

No, dichas exclusiones implican que no será de aplicación para tales operaciones el RRSIF.No obstante, debe considerarse que incluso en los supuestos excluidos de facturación por el artículo 3.1.a ROF, existen excepciones señaladas en el artículo 2.2 del ROF que exigen la emisión de factura. En tales casos, el obligado tributario deberá cumplir las obligaciones del reglamento que establece los requisitos de los sistemas informáticos de facturación en el caso de que expida facturas, siempre que cumpla también con el resto de condiciones indicadas (“regla de los 4 «NO»”).Normativa/Doctrina:• Artículo 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículos 3.1.a, 3.2 y 2.2 del Reglamento por el que se regulan las obligaciones de facturación, aprobado Real Decreto 1619/2012, de 30 de noviembre.

La normativa contempla a los obligados tributarios de forma individualizada (no por grupos) en los que se refiere a sus obligaciones de facturación, por lo que, aunque pertenezcan al mismo grupo de empresas, deberán cumplir con sus obligaciones de facturación con arreglo a su condición. Por lo tanto, el SIF de cada sociedad debe cumplir con las obligaciones de facturación que le correspondan a la misma. Debe señalarse no obstante que voluntariamente las entidades de un grupo pueden darse de alta en el SII a fin de mantener una homogeneidad de gestión con el grupo al que pertenezcan.Por otro lado, existen productos de mercado capaces de aplicar los requisitos de ambas normativas.Normativa/Doctrina:

• Artículo 3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

En el supuesto de que el empresario individual estuviera obligado a expedir factura (ordinaria o simplificada), desde el momento que utiliza un sistema informático de facturación consistente en una caja para registrar las ventas realizadas e imprimir para cada una de ellas lo que debería ser una factura simplificada para entregar al cliente está sujeto al RD 1007/2023, de 5 de diciembre, y al reglamento por él aprobado, por lo que deberá cumplirlo, bien adaptando las cajas registradoras (si esto fuera posible), bien adquiriendo algún sistema informático de facturación (SIF) adaptado.En cuanto a la balanza electrónica, si el empresario o profesional la utiliza solo para pesar el producto y obtener el importe que luego introduce manualmente en la caja registradora para expedir la factura simplificada final, no se consideraría SIF, sino un elemento -independiente- auxiliar de medida (y, en su caso, de cálculo del importe asociado al producto, según su precio por kilogramo). En este caso, el SIF sería la caja registradora, por lo que la balanza electrónica no tendría por qué adaptarse al RD 1007/2023.Sin embargo, hay balanzas electrónicas con funcionalidades más potentes que permiten acumular los importes de los diferentes productos pesados y expedir en unidad de acto una factura simplificada de la compra total realizada (entre otras posibles funcionalidades), por lo que entonces sí serían consideradas SIF al ser utilizadas también como cajas registradoras. Dicho de otro modo, serían SIF con otros elementos electrónicos auxiliares (en este caso, para el pesaje) añadidos. Si es así, entonces deberían adaptarse al RD 1007/2023 y al reglamento por él aprobado. Las conexiones a internet pueden gestionarse a través de líneas telefónicas y, por otra parte, los sistemas de emisión de facturas no verificables permiten la custodia de los ficheros en la sede local.Normativa/Doctrina:• Artículo 3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí, TODAS las operaciones respecto de las cuales empresarios y profesionales (personas físicas o jurídicas) deban emitir factura con arreglo a la normativa vigente (especialmente de acuerdo con el Reglamento de Obligaciones de Facturación aprobado por RD 1619/2012) se someten al RRSIF. Lo anterior incluye tanto las exportaciones como las entregas intracomunitarias de bienes y las prestaciones internacionales o intracomunitarias de servicios.Normativa/Doctrina:• Artículos 1, 3 y 4 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí, cuando el empresario no residente disponga de un establecimiento permanente a los efectos de la normativa del Impuestos sobre la Renta de no Residentes (Real Decreto Legislativo 5/2004, de 5 de marzo).Normativa/Doctrina:• Artículo 1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí. El reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre, prevé en su artículo 5 la posibilidad de que se solicite la no aplicación del o de algún aspecto del mismo cuando concurran determinadas circunstancias, que se entienden extraordinarias, relacionadas con la actividad económica o de índole técnica.La solicitud se podrá presentar a través de la sede electrónica de la Agencia Tributaria.Normativa/Doctrina:• Artículo 5 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí. Se puede delegar en el destinatario de la operación o en un tercero el cumplimiento material de las obligaciones del reglamento que establece los requisitos de los sistemas informáticos de facturación siempre que se den las condiciones establecidas en el artículo 5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, a los efectos de la obligación de expedir de la factura, con facultades otorgadas para ello.En cualquier caso, esta posibilidad no exime al obligado a expedir facturas de la responsabilidad sobre dicho cumplimiento.Normativa/Doctrina:• Artículo 6 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

Antes de nada, debe tenerse en cuenta que el objeto regulado en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre, son precisamente los sistemas informáticos de facturación (SIF), que es diferente de la obligación de la llevanza de libros registros de IVA (LRI). Son por tanto obligaciones diferentes que pueden afectar a obligados tributarios distintos.En el caso planteado, y por lo que se refiere a las obligaciones impuestas por el RRSIF, si el proveedor ha delegado la expedición material de la factura en su cliente, es el cliente quien, además de expedir materialmente dicha factura, deberá generar -y, en la modalidad «VERI*FACTU», remitir- el registro de facturación de alta que exige el RRSIF. No obstante, si el cliente lleva los libros registros de facturación en los términos establecidos en el artículo 62.6 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre, (mediante el suministro inmediato de información, o SII) queda excepcionado del cumplimiento de las obligaciones previstas en el RRSIF para dichas operaciones.Por otro lado, en relación con la llevanza de los LRI, es independiente de quién expida materialmente las facturas, y se encuentra regulada en los artículos 62 y 63 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre. Por lo tanto, cada empresa deberá incluir las facturas expedidas por todos los bienes vendidos y servicios prestados (independientemente de quién haya expedido materialmente la factura, pudiendo ser la propia empresa vendedora, un tercero o el destinatario/comprador) en el LRI de facturas expedidas, y las facturas recibidas de los bienes comprados o servicios recibidos (independientemente de quién haya expedido materialmente la factura, pudiendo ser la empresa vendedora, un tercero o el destinatario/comprador) en el LRI de facturas recibidas.Normativa/Doctrina:Artículos 5 y 6 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre, modificado por el Real Decreto 254/2025, de 1 de abril.Artículo 5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre.Artículos 62 y 63 del reglamento del Impuesto sobre el Valor Añadido (RIVA), aprobado por el Real Decreto 1624/1992, de 29 de diciembre

Esta pregunta se refiere a los recursos informáticos necesarios para llevar a cabo dicho cumplimiento y la respuesta se encuentra en el artículo 7 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Se puede resumir en que debería utilizar un sistema informático de facturación (SIF) adaptado al RRSIF, que podría ser:SIF existente en el mercado, gratuito o de pago: artículo 7.a. Podría estar instalado en las dependencias de quien expida las facturas (on-premise), en remoto, o bien en la nube (cloud).SIF desarrollado internamente por quien expida las facturas: artículo 7.a.La aplicación básica de facturación que ofrecerá gratuitamente la Agencia Tributaria en su sede electrónica, siempre y cuando sus funcionalidades y condiciones de uso se ajusten a las necesidades de quien la vaya a utilizar: artículo 7.b.Por último, se recuerda que existe la posibilidad de delegar en un tercero o en el destinatario de la operación la expedición material de las facturas, que deberá realizarse cumpliendo el RRSIF. Existen otras preguntas frecuentes que tratan sobre este aspecto.

Aunque no está mencionado en el RRSIF, debe señalarse que se ha ampliado el plazo de presentación de solicitudes del SEGMENTO III (entre 0 y de 3 empleados) del KIT DIGITAL, hasta el 31/10/2025. Este Programa está financiado con fondos del Plan de Recuperación Transformación y Resiliencia y tiene como objetivo el impulso al «Plan de Digitalización de las PYMEs 2021-2025». El importe máximo de ayuda por beneficiario será de dos mil euros (2.000 €). Y entre las soluciones financiables se encuentra la de Gestión de Procesos en la que se encuadran los Sistemas Informáticos de Facturación.Por otro lado, el Reglamento SIF (aprobado por RD 1007/23) prevé en su artículo 7.b la creación de una aplicación informática que será desarrollada por la Administración tributaria y que servirá para cumplir con el Reglamento SIF en su modalidad VERI*FACTU. Esta aplicación podría servir también más adelante para facilitar la emisión de facturas electrónicas B2B.

Resumidamente, debe:Garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación que está obligado a generar por cada factura expedida, en los términos del RRSIF y de su OM, generando un fichero de alta de factura por cada una de las expedidas. Además, debe imprimirse un código QR en las condiciones específicamente reguladas.Tener la capacidad de comunicación con la AEAT para la remisión de los mismos.Además, si se tratan datos personales, debe cumplir con las medidas previstas en la legislación en materia de protección de datos para lo cual debe disociar o separar el acceso a la información tributaria de otro tipo de información confidencial, de manera que la Agencia Tributaria pueda acceder a la primera.Por último, el SIF deber registrar ciertos eventos que sucedan en el mismo (a menos de que se trate de un SIF funcionando en modo VERI*FACTU).Los detalles concretos sobre cómo han de implementarse estos requisitos se aclaran en otras preguntas frecuentes.Normativa/Doctrina:• Artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.• Artículos 7 y 8 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí, pero con ciertas condiciones. En el artículo 7.a del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre, se prevé tal posibilidad siempre que los registros de facturación de cada obligado tributario se encuentren diferenciados y se cumplan los requisitos exigidos en el RRSIF por separado para cada uno de los obligados tributarios. Es decir, el sistema deberá comportarse como si fuera un SIF «propio» e independiente para cada OEF.Esto se traduce en que debe gestionar separadamente los registros de facturación y, en su caso, de evento de cada OEF incluido en el SIF, cumpliendo con los requisitos exigidos en los artículos 7.a y 8 del RRSIF, con encadenamiento independiente para dichos registros de cada OEF. Asimismo, deberá poder permitir el funcionamiento del SIF en la modalidad «VERI*FACTU» de forma independiente para cada OEF. Adicionalmente, deberá visualizar, claramente y en todo momento, la información identificativa del OEF al que corresponde la operativa que se está realizando en cada instante. Además, en el caso de que efectivamente esté soportando la facturación de más de un OEF, independientemente del estado operativo en que se encuentren, bien sea de alta, de baja o cualquier otro, deberá indicarlo con algún mensaje explicativo que pueda ser consultado de forma rápida, fácil e intuitiva.Normativa/Doctrina:• Artículos 7 y 8 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 2 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

No. Cualquier funcionalidad o mecanismo del SIF que permita alterar los registros de facturación una vez generada la factura o el rastro de las operaciones supone un incumplimiento de los requisitos exigidos por el reglamento.A estos efectos, se entiende por alteración de los registros de facturación, la ocultación o eliminación de cualquier registro de facturación originalmente generado y registrado por el sistema informático, o la ocultación o modificación, total o parcial, de los datos de cualquier registro de facturación originalmente generado y registrado por el sistema informático, o la adición de registros de facturación, simulados o falsos, distintos a los originalmente generados y registrados por el sistema informático.Cualquier necesidad de corrección o anulación de los datos obligatorios registrados deberá ser realizada mediante los procedimientos regulados en el reglamento y su orden ministerial, generando al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados y los corregidos.Normativa/Doctrina:• Artículos 8.2.a y 8.2.b del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La limitación viene dada por la operativa de digitación de la información contenida en el formulario. Lo lógico es que dicha aplicación de uso subsidiario se utilice por microempresarios o profesionales con un número limitado de facturas emitidas al año.

Sí, la potencial conexión de todos los sistemas informáticos de facturación con la Agencia Tributaria viene obligada por el artículo 8.1 del RRSIF que establece:El sistema informático deberá tener capacidad de remitir por medios electrónicos a la Administración tributaria, de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente, todos los registros de facturación generados a que se refieren los artículos 9, 10 y 11 de este Reglamento.Por lo tanto, la normativa obliga a que todos los sistemas informáticos de facturación tengan la capacidad de comunicar con la AEAT y, por ejemplo, ante un requerimiento de la Agencia Tributaria puedan comunicar directamente los registros que le son requeridos, o bien, adoptar en cualquier momento la modalidad VERI*FACTU, con remisión inmediata en línea a la AEAT.Normativa/Doctrina:• Artículo 8.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

El tipo de firma electrónica a utilizar por parte de los desarrolladores de software para cumplimentación de la obligación de firmar los ficheros de alta o anulación de facturas puede ser distinto de los utilizados por la AEAT, siempre que sea firma cualificada y sirva a la finalidad de autenticar y hacer inmutable el contenido del registro de facturación de alta.

Si todos los sistemas informáticos mencionados (tanto el central como el de la sede "desconectada") expiden independientemente facturas, cada una con su QR incluido, serán ambos sistemas considerados sistemas informáticos de facturación (SIF) independientes, según el artículo 1.2 del reglamento aprobado por el RD 1007/2023, de 5 de diciembre (RRSIF) y, por lo tanto, cada uno de ellos debe cumplir separadamente dicho RRSIF.Así, cada uno de ambos SIF, al mismo tiempo que expiden cada factura deben generar su correspondiente registro de facturación (RF) de alta. Estos Registros de Facturación deberán estar encadenados (con el hash correspondiente) de forma independiente dentro de cada SIF, respetando la secuencia de generación de los mismos, es decir, de acuerdo al orden en el que fueron generados en cada uno de ellos. Por lo tanto, para expedir sus propias facturas (y generar los correspondiente Registros de Facturación asociados, de forma encadenada) no tienen por qué -ni necesitan- saber qué facturas están expidiendo otros SIF de la misma sociedad o empresa, ya que son independientes a estos efectos y no necesitan para ello estar "conectados o comunicados" entre sí.

Sí, ya que ambos SIF pueden cumplir con la norma en distintas modalidades. No obstante, se significa que no es esta la opción preferible ya que generará en los registros disponibles en sede electrónica de la AEAT listados incompletos de facturas emitidas, que harán preciso completar mediante requerimientos.

No, ese volcado ulterior no es en sentido propio una facturación, puesto que los clientes ya se habrán llevado las facturas impresas y, por lo tanto no cabe esa remisión ”en diferido”.

Un SIF cumplidor del reglamento y la orden debería garantizar que no se den ese tipo de circunstancias o que es capaz de recuperarse adecuadamente ante las mismas y seguir cumpliendo el reglamento y la orden, estableciendo las medidas y procedimientos necesarios para ello.

Significa que el SIF deberá tener una forma diferenciada de acceder a las funcionalidades y a los datos con trascendencia tributaria exigidos en el reglamento, de manera que quede preservada la confidencialidad de otros datos distintos y no se pueda acceder indebidamente a ellos por esa vía. Esto se prevé sobre todo en el caso de que se produzca una personación de algún miembro de la Agencia Tributaria para inspeccionar in situ el SIF, siempre cumpliendo con los procedimientos establecidos al respecto.

El SIF deberá garantizar la integridad e inalterabilidad, la trazabilidad, y conservación de los registros de facturación, en los términos establecidos en el artículo 8 del RRSIF y su normativa de desarrollo. Además, deberá contar con un registro de eventos en el que se recojan determinadas interacciones con el sistema determinadas por orden ministerial (entre otras, la detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación o en el propio registro de eventos).Por lo que se refiere a los desarrolladores y su responsabilidad, deberán afrontar las exigencias reglamentarias para hacer posible asegurar que, durante el periodo de conservación de los registros, no se han producido interacciones indebidas sobre los mismos que los hayan alterado, modificado, interpolado, suprimido o regenerado. Igualmente deberán certificar a sus clientes que cumplen con esas exigencias. Naturalmente el régimen sancionador al que se refiere el artículo 201.bis de la LGT debe tener en cuenta a la hora de sancionar los comportamientos de los fabricantes de sistemas y de los usuarios si ha concurrido en sus comportamientos culpabilidad, incluso a título de mera negligencia, o se ha producido la destrucción o hackeo de los códigos del programa.

No, un registro de facturación, una vez generado (y firmado / remitido a la AEAT según la modalidad empleada) no debe ser modificado nunca por nadie (si se hiciera, se podría detectar: gracias a la huella, firma, encadenamiento...). Cualquier “cambio” que se desee hacer constar sobre el mismo, deberá realizarse a través de la generación de uno o más -según se necesite- registros de facturación nuevos, del tipo que corresponda a cada caso (normalmente -y de forma preferente- utilizando los procedimientos establecidos por el reglamento de obligaciones de facturación). Si por corregir se refiere a “recuperar” de algún modo lo que ya estaba generado, pero se había “perdido” o “corrompido”, la respuesta debe ser la contraria.En cuanto a la corrupción de datos, se recuerda que se debe cumplir con todos los requisitos que exige el reglamento y la orden, siendo en este caso de especial importancia la conservación (y también la legibilidad, accesibilidad e integridad inalterabilidad), por lo que deberán ponerse los medios necesarios para impedir la corrupción y garantizar la conservación.Finalmente, sobre la cuestión de la migración, el reglamento y la orden no entran en lo que se haga posteriormente con los registros de facturación generados (como su posible envío a otros sistemas con idea de utilizarlos para otros fines), más allá de exigir su conservación, legibilidad y accesibilidad a futuro durante el plazo de conservación.

Un registro de facturación con errores se debe subsanar mediante la generación de un nuevo registro de facturación y, en su caso, su remisión en los sistemas VERI*FACTU (ya que no se puede alterar el registro erróneo si ya se emitió).De acuerdo con el diseño de registro que se publicará en la Orden Ministerial (ya disponible en la Sede electrónica de la AEAT), esta nueva generación de un registro de facturación deberá llevar 'Tipo de registro'="Sustitutivo" e indicador SubsanaError a "S". Con ello la trazabilidad no se ve afectada, ya que esta va ligada a los registros de facturación según el orden temporal de su generación, no a las facturas a las que estos referencian.

El reglamento que aprueba el RD 1007/2023, de 5 de diciembre, y la Orden Ministerial que lo desarrolla solo aplican a los sistemas informáticos de facturación (SIF), es decir, aquellos sistemas que son utilizados para expedir facturas o facturas simplificadas. Cualquier otro sistema informático que no sea de facturación, en principio no se ve afectado por la normativa.Los requisitos generales de trazabilidad que emanan del literal del artículo 29.2.j determinan que, a efectos informáticos, el sistema de generación de pre-facturación, borradores o proformas sin validez fiscal, debe estar vinculado indefectiblemente al Sistema de emisión de facturas, formando una unidad. Por ello y por razones de control interno, conviene que se conserven registros de las prefacturas o facturas proforma elaboradas.Por ello, no sería legal y sería susceptible de sanción, el uso de sistemas que generen documentos preparatorios de facturas o de facturas simplificadas, sin que el sistema informático mismo disponga de elementos de control para la conservación de tales documentos preparatorios de forma debidamente vinculada a las facturas o a los registros de facturación que finalmente se emitan o, en defecto de factura, de forma que queden registrados y conservados en el sistema.

Como el registro de facturación se genera inmediatamente antes de expedir la factura, se debe entender que en el momento de generar dicho registro que, además, o bien será remitido a la AEAT, o bien será firmado.

Se puede subsanar (tipo registro Sustitutivo) cualquier dato al que el reglamento de facturación no imponga la emisión de una factura rectificativa. En cualquier caso, si el dato modificado de la factura no está en el registro de facturación generado y firmado / remitido (ni afecta a ninguno de los campos de este), propiamente no habría que subsanar nada del registro de facturación generado y firmado / remitido. Pudiéndose cambiar sin que ello afecte a la integridad del fichero.

Si la pérdida solo afecta a registros de facturación, en un sistema VERI*FACTU esta situación sería menos problemática pues los registros los tendría la AEAT y el obligado podría recuperarlos en su integridad. En un sistema de emisión de facturas no verificables, es el empresario el que debe velar por la conservación de los registros de facturación, tal y como se fija en la norma, sin que quepa negar la posible existencia de casos de fuerza mayor que excluirían la culpabilidad y podrían dar lugar a determinar las bases imponibles por el método de estimación indirecta.

La trazabilidad se refiere a que se pueda garantizar (y, en su caso, detectar) que no hay “huecos” o “saltos” en la secuencia de generación de los registros de facturación (RF) correspondientes a las facturas expedidas utilizando un determinado SIF de un obligado tributario (OT), así como que dicha secuencia se corresponde con la de la fecha y hora de generación empleadas.Esto se consigue “encadenando” los RF generados por cada SIF del OT, es decir, formando virtualmente una “cadena” debido a que dentro de los datos de cada RF generado figuran ciertos datos (ver abajo, al pie de esta respuesta, la NOTA 1) del RF generado inmediatamente antes (y que, por tanto, permiten identificarlo), actuando a modo de “puntero” hacia él. Si esta cadena se viese alterada de algún modo (ruptura de la secuencia de punteros, fechas y horas no coherentes…), este hecho podría ser detectado.En definitiva, con la implementación de la trazabilidad se puede saber si se cuenta con todos los RF generados por un SIF de un OT y si estos están en el mismo orden secuencial en que fueron generados.Por último, mencionar que los sistemas de emisión de facturas no verificables también deben garantizar la trazabilidad de los registros de evento que generen, de una forma equivalente a como lo realizan para los RF.NOTA 1: los datos que intervienen en el encadenamiento se pueden ver en los correspondientes diseños de registros del anexo de la orden, pero básicamente son la identificación de la factura (emisor, nº de serie y nº de factura, fecha de expedición) a la que hace referencia el RF anterior y “parte” de la huella del RF anterior (actualmente se trata de toda la huella).Normativa/Doctrina:Artículos 8.2.b del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículo 7 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Los registros de facturación (RF) se deben encadenar de forma independiente dentro de cada SIF, y para cada OT (en el caso de que el SIF gestione la facturación de varios OT). Es decir, debe existir una única cadena de RF por cada par de valores distintos de (SIF; OT).Por lo tanto, la respuesta a esta pregunta dependerá de cómo tenga organizado cada OT su forma de facturar y del número de OT cuya facturación se gestione en cada SIF empleado.En relación con lo 1º (la organización de la forma de facturar por parte del OT), por ejemplo, si un OT dispone de varios TPV (en uno o diversos centros de venta, o tiendas) que expiden o gestionan la expedición de sus propias facturas de forma independiente a las del resto de TPV, cada TPV se considera que es un SIF, de acuerdo a la definición dada en el reglamento, así que deberá poseer su propia cadena de RF. De esta manera, el OT tendrá tantas cadenas de RF como TPV tenga.En relación con lo 2º (número de OT gestionados por el SIF), si un SIF permite la gestión de la facturación de varios OT (como puede ser el caso de un SIF utilizado por una gestoría para llevar en él la facturación de varios OT que son clientes de esa gestoría), dicho SIF deberá tener una cadena independiente por cada OT cuya facturación gestione.

La respuesta a esta pregunta se deriva de la definición y explicación dada (ver otras preguntas frecuentes de este apartado) sobre el concepto de trazabilidad, y es que se limita al ámbito del propio SIF (para cada OT, si permite gestionar la facturación de varios OT). Es decir, una vez que el SIF implementa la trazabilidad mediante el completo y correcto encadenamiento -y fechado- de los RF generados (sin olvidar su firma y guardado -por los sistemas de emisión de facturas no verificables- o remisión -por los SIF VERI*FACTU- a la Agencia Tributaria), ya está cumplida y los RF son rastreables.A partir de ese momento, el reglamento y la orden no entran en lo que se haga posteriormente con los RF generados por el SIF (ver abajo, al pie de esta respuesta, la NOTA 1), más allá de exigir su conservación, legibilidad y accesibilidad a futuro en el caso de sistemas de emisión de facturas no verificables.Por lo tanto, la trazabilidad no se refiere al intercambio de los RF generados por un SIF con otros sistemas informáticos, ni a que esto sea rastreable.NOTA 1: un ejemplo de esta posibilidad, en la práctica muy frecuente, sería el posible envío posterior de los RF generados por el SIF a otros sistemas informáticos distintos con idea de utilizarlos para fines diversos: contabilidad, gestión de stocks… Tampoco se exigirían requisitos al respecto a estos sistemas informáticos destinatarios (diferentes al SIF) a los que les lleguen los RF generados en otro SIF.

No. Un SIF tiene una única cadena de RF (por cada obligado tributario que gestione, en el caso de que gestione varios dentro de él) en la que se encadenan ambos tipos de RF (alta y anulación) indistintamente, en el mismo orden secuencial en el que hayan sido generados.

Efectivamente, forman parte del mecanismo de trazabilidad de los RF, ya que dichos campos deberían ser coherentes con el orden temporal de generación de los RF que conforman la cadena de RF del sistema informático de facturación (SIF). Por lo tanto, esta es una de las cuestiones que el SIF debería garantizar que se hace correctamente.Además, en el caso de tratarse de sistemas de emisión de facturas no verificables, el SIF también debería ser capaz de detectar e informar de incongruencias encontradas al respecto en los RF generados que se encuentren a su alcance.

No. Es práctica habitual por parte de los obligados a expedir facturas (OEF) “cambiar” la numeración de sus facturas con el cambio de año, ya que suelen incluir dicho año dentro de la propia numeración de las facturas. Sin embargo, esto no afecta en nada a la trazabilidad. Son dos cuestiones completamente independientes. La trazabilidad solo exigiría que el RF de la primera factura expedida en el nuevo año fiscal se encadene correctamente con el RF de la última factura expedida en el año anterior, independientemente del número de factura (o de serie) que tengan.

No. Cuando en un sistema informático de facturación (SIF), de manera justificada, haya que generar un RF de anulación de una factura expedida indebidamente (en ese SIF o en otro) o un RF de alta de subsanación de ciertos errores detectados en alguna factura expedida (en ese SIF o en otro), estos irán encadenados con el anterior registro de facturación generado por el SIF en el que se está haciendo la operación de anulación o subsanación. Es decir, en cuanto a trazabilidad, a la hora de encadenar estos RF se tratan como un RF más del SIF en el que se realiza la operativa.

Deberá actuar de igual forma que cuando detecta un error en la integridad e inalterabilidad de algún RF (ver en el apartado correspondiente la pregunta frecuente equivalente).Por último, recordar que solo los sistemas de emisión de facturas no verificables están obligados a poder detectar estos errores en la trazabilidad de los RF y registros de evento generados que estén a su alcance. Ver al respecto, dentro de este mismo apartado, la contestación a una pregunta frecuente con más detalles.

No, los sistemas de emisión de facturas no verificables tienen más obligaciones, al no remitir los registros de facturación (RF) generados a la Agencia Tributaria, por lo que es necesario que refuercen los mecanismos de control al respecto.Hay que decir que ambos tipos de SIF, sistemas VERI*FACTU y sistemas de emisión de facturas no verificables, tienen las mismas obligaciones en cuanto a implementar y garantizar la trazabilidad mediante el correcto encadenamiento de los RF (y también, por su parte, de los registros de evento en el caso de los sistemas de emisión de facturas no verificables). Sin embargo, a partir de este momento, los SIF VERI*FACTU ya no tienen más obligaciones relacionadas con este requisito.Por el contrario, los sistemas de emisión de facturas no verificables están también obligados a detectar fallos (y a ofrecer funcionalidades que lo permitan hacer) en el encadenamiento de los RF y de los registros de evento generados que estén a su alcance, avisando cuando se produzca esta circunstancia, además de generar el correspondiente registro de evento.Por otro lado, los obligados tributarios (OT) usuarios de los sistemas de emisión de facturas no verificables también son responsables de garantizar la precisión de la hora de fechado con un margen máximo de error de un minuto, cosa que no aplica a los OT de los SIF VERI*FACTU.

El lugar donde se conserven los RF será, en última instancia, una decisión del obligado a expedir factura (OEF) que utiliza el SIF (puede que en función de las circunstancias y de las características que tenga dicho SIF).En este punto, se debe recordar que los SIF VERI*FACTU (y los OEF que los utilicen) no están obligados a conservar los RF generados, ya que se han remitido a la Agencia Tributaria y, por tanto, obran en poder de esta.Aclarado este matiz, en principio, el SIF almacenará bajo su control (ver abajo, al pie de esta respuesta, la NOTA 1 los RF que genere (puede que, por limitaciones de almacenamiento, necesite en algún momento que los RF sean exportados y eliminados de él para dejar espacio libre). En cualquier caso, el SIF debe ofrecer un procedimiento de descarga, volcado y archivo seguro de los registros de facturación generados por él, que deberán poder ser exportados a un almacenamiento externo en formato electrónico legible.Normativa/Doctrina:• Artículos 8.2.c del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 8 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.NOTA 1Los RF generados pueden almacenarse remotamente, incluso “en la nube”, con tal de cumplir con toda la normativa que les sea de aplicación, y, en particular, con lo exigido en el reglamento y en la orden de requisitos de los SIF, especialmente en lo referido a su accesibilidad.

Efectivamente, para que el SIF pueda dejar de conservar “dentro de él” los RF que ha generado, esto solo puede realizarse mediante una operación de exportación ejecutada correctamente y que admita la posibilidad de dejar de conservarlos en él.Antes de continuar con la respuesta, ha de recordarse que este asunto relacionado con la exportación de los RF generados solo aplica a los sistemas de emisión de facturas no verificables, ya que los SIF VERI*FACTU no están obligados a guardar los RF que generan ni a ofrecer su exportación (aunque podrían hacer voluntariamente ambas cosas), ya que los remiten a la Agencia Tributaria y, por tanto, obran en poder de esta.Aclarado lo anterior, ha de decirse que, aunque para el SIF es obligatoria la existencia de la funcionalidad de exportación de los RF generados por dicho SIF, no es obligatorio ofrecer la posibilidad de que dicha funcionalidad permita la eliminación de los mismos del SIF, es decir, dejar de conservarlos “dentro” del SIF (bajo su gestión y control). Por lo tanto, este es un aspecto que dependerá de las características del SIF: si no tiene esta opción, estará obligado a conservar dentro de él -bajo su gestión y control- y para siempre todos los RF generados. Por otro lado, aunque tenga disponible dicha opción, dependerá del obligado a expedir factura (OEF) usuario del SIF si la utiliza o no (aunque, en la práctica, podría verse “forzado” a ello por diversas causas, como limitaciones en el rendimiento o en la capacidad del almacenamiento del SIF).Por lo tanto, lo más probable es que, en general, los sistemas de emisión de facturas no verificables ofrezcan esta posibilidad de exportación de RF generados que suponga dejar de conservarlos en el SIF.Los requisitos para el uso de esta opción serán los siguientes:• Que forme parte del proceso de exportación y solo sea accesible desde dicha funcionalidad.• Que antes de que sea llevada a cabo se avise claramente al usuario del SIF de lo que implica ejecutar esa opción (dejar de conservar los RF en el SIF, estando ya solo disponibles fuera de él, bajo la responsabilidad del OEF usuario del SIF), dándole la oportunidad de continuar o cancelar el proceso.• En el caso de que el OEF usuario del SIF acepte continuar, el SIF solo podrá dejar de conservar los RF generados y exportados en dicho proceso cuando este acabe correctamente.• Además, solo podrá dejar de conservar los RF exportados cuando ello no suponga el incumplimiento por parte del SIF de ningún requisito del reglamento y la orden «de requisitos de los SIF». Por ejemplo, si el método empleado por el SIF para llevar a cabo la obligación de verificar la correcta trazabilidad del último RF generado (antes de poder generar el siguiente RF) es consultar expresamente dicho último registro y el anterior, no podrá dejar de conservar estos dos registros.• Por último, para evitar la aparición de huecos entre los registros de facturación conservados en el SIF, esta posibilidad de dejar de conservar los RF exportados solo podrá aplicarse a RF consecutivos, empezando siempre por los más antiguos que aún se conserven en el SIF. Es decir, no se podrá ofrecer al OEF usuario del SIF la posibilidad de que “exporte y deje de conservar en el SIF” RF generados si estos no empiezan desde el principio de la cadena de RF que obra en poder del SIF (debiendo ir además seguidos, como si formaran un bloque).

No. El proceso de exportación que permita la descarga, volcado y archivo seguro de los registros de facturación generados por él debe ser una funcionalidad adicional específica (con sus propias características) del SIF, diferente a los procedimientos de copia de seguridad de los que disponga el SIF o la instalación informática en la que este resida.Se recuerda que la funcionalidad de exportación solo es exigible a los sistemas de emisión de facturas no verificables, es decir, que los SIF VERI*FACTU no están obligados a disponer de ella.

Cada uno tiene su parte de responsabilidad:• El productor (fabricante) del SIF es responsable de que el SIF genere y guarde o remita los RF en el tiempo y forma exigidos, así como que proporcione acceso rápido, fácil e intuitivo a los mismos mientras se encuentren en dicho SIF, junto con un procedimiento de descarga (exportación) seguro. Por lo tanto, el productor (fabricante) del SIF, que ha firmado una declaración responsable sobre dicho SIF, es responsable de que este cumpla con los requisitos que exige la normativa a este respecto.• El OEF usuario del SIF es responsable de asegurarse de que conserva durante el plazo previsto para tal fin los RF generados, incluso aunque haya dejado de usar el SIF que los generó. Es por ello muy recomendable -y se considera una buena práctica- que el OEF exporte frecuentemente los RF generados por el SIF y los conserve de forma redundante en un sitio seguro.En todo caso, se recuerda que la conservación de los RF solo es exigible a los sistemas de emisión de facturas no verificables y a los OEF usuarios de este tipo de SIF. Por lo tanto, los SIF VERI*FACTU y los OEF usuarios de estos no están obligados a conservar los RF generados (aunque pueden hacerlo), ya que los han remitido a la Agencia Tributaria.

Se trata del mismo plazo exigido en el artículo 19.1 del Reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, para la conservación de las facturas expedidas (ver abajo, al pie de esta respuesta, la NOTA 1).En la LGT (Ley 58/2003, de 17 de diciembre, General Tributaria) hay diversas menciones a plazos (ver abajo, al pie de esta respuesta, la NOTA 2) para varios aspectos, con sus matices y excepciones. Por otro lado, la LIVA (Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido) contempla sus propios plazos (ver abajo, al pie de esta respuesta, la NOTA 3), según el artículo 165 de la LIVA y el apartado 6.4 del manual de facturación de 2011 (ver abajo, al pie de esta respuesta, la NOTA 4). También se puede encontrar en la pregunta 4 del manual práctico IVA 2023 (ver abajo, al pie de esta respuesta, la NOTA 5) una referencia a plazos de conservación de más de 10 años para ciertas facturas.Por ello, cabría concluir que el plazo depende de la operación de que se trate y las circunstancias que concurran, pudiendo oscilar entre un mínimo de 4 años a partir del plazo de presentación de la declaración o autoliquidación correspondiente al ejercicio o periodo impositivo que aplique a dicha factura hasta más de 10 años en algunos casos.Se acompaña esta respuesta de las mencionadas notas 2 a 5 con documentación y ejemplos al respecto.NOTA 1:No se debe confundir la conservación de las facturas exigida por el ROF con la conservación de los RF exigida por el reglamento y la orden «de requisitos de los SIF». Ambos (factura y RF) son productos diferentes y están regulados por distinta normativa.NOTA 2:Algunos plazos mencionados en la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT):Artículo 66: 4 años para ciertos derechos.Artículo 66 bis, especialmente su apartado 2, sobre el derecho a comprobar e investigar bases o cuotas compensadas o pendientes de compensación o de deducciones aplicadas o pendientes de aplicación: 10 años a contar desde el día siguiente a aquel en que finalice el plazo reglamentario establecido para presentar la declaración o autoliquidación correspondiente al ejercicio o periodo impositivo en que se generó el derecho a compensar dichas bases o cuotas o a aplicar dichas deducciones.Artículos 70.2 y 70.3: se mencionan otros plazos, pudiendo ser superiores a 4 años (plazo previsto en la normativa mercantil; plazo de exigencia de sus propias obligaciones formales al que se refiere el apartado anterior, si este último fuese superior; obligación de justificar la procedencia de los datos que tengan su origen en operaciones realizadas en períodos impositivos prescritos se mantendrá durante el plazo de prescripción del derecho para determinar las deudas tributarias afectadas por la operación correspondiente).Artículo 115, en el que se recoge que las potestades y funciones de comprobación e investigación pueden exceder los 4 años previstos en el artículo 66 para investigar otros derechos que no hubieran prescrito.NOTA 3(Aunque en este caso se refiere a las facturas recibidas, aplica también a las expedidas, según el artículo 165 de la LIVA):Pregunta¿Cuál es el plazo durante el cual deben conservarse las facturas recibidas?RespuestaCon carácter general, cualquier factura recibida debe conservarse durante el período de prescripción -cuatro años- del impuesto. No obstante, si la factura se refiere a la adquisición de un bien que tenga que ser objeto de regularización, deberá ser conservada durante su período de regularización y los cuatro años siguientes. Si se realizan operaciones que tengan por objeto oro de inversión, las facturas y registros correspondientes a tales operaciones deben mantenerse durante cinco años.Normativa/Doctrina:Artículo 165 Ley 37/1992, de 28 de diciembre de 1992, del Impuesto sobre el Valor Añadido (LIVA).Artículo 140 Sexies Ley 37/1992, de 28 de diciembre de 1992, del Impuesto sobre el Valor Añadido (LIVA).NOTA 4Apartado 6.4 del manual de facturación de 2011:6.4 Plazo de conservación.Los documentos de facturación deben conservarse durante el plazo previsto en la Ley General Tributaria.Cuando las facturas recibidas o expedidas se refieran a adquisiciones por las cuales se hayan soportado cuotas del Impuesto sobre el Valor Añadido cuya deducción esté sometida a un período de regularización, deberán conservarse durante su correspondiente periodo de regularización y los cuatro años siguientes.Por otra parte, los empresarios o profesionales que realicen operaciones que tengan por objeto oro de inversión, deberán conservar las copias de las facturas correspondientes a dichas operaciones durante un período de cinco años. (artículo 140 sexies LIVA).Manual de facturación. NOTA 5:Pregunta 4 del manual práctico IVA 2023, conteniendo un ejemplo referido al artículo 165.Uno de la LIVA, sobre el artículo 107.Cuatro de la LIVA, que trata las regularizaciones:4.¿Durante cuánto tiempo debe conservarse la factura de compra de un edificio?Si se comienza a utilizar el mismo año de la adquisición, debe conservarse durante 14 años: el año de compra, los 9 años siguientes por ser el período de regularización y los 4 siguientes.Si se comienza a utilizar en años posteriores a la adquisición, debe tenerse en cuenta que el período de regularización comienza el año de utilización y que deben incrementarse los años en que deben conservarse las facturas.Manual de IVA 2023.

Por accesibilidad debe entenderse el proporcionar acceso rápido, fácil e intuitivo a las funcionalidades exigidas al SIF por el reglamento y la orden, así como a los RF generados por el SIF , bien para consultarlos o para descargarlos de forma segura y fidedigna, independientemente de dónde y cómo se encuentren almacenados y conservados. Todo ello deberá, además, hacerse preservando al mismo tiempo la confidencialidad de otros datos distintos a los exigidos en el reglamento y la orden.La accesibilidad debe ser garantizada tanto por el SIF (con el matiz hecho de que lo referente a los RF solo aplica cuando los RF se encuentren en él) como por el obligado a expedir factura (OEF) usuario del SIF .En cuanto a la legibilidad, se refiere a que los RF generados tengan la estructura, contenido y formato exigidos, de forma que, mediante procesos electrónicos automáticos, puedan ser leídos y entendidos.Normativa/Doctrina:• Artículos 8.2.c del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 8 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

En que el sistema informático de facturación (SIF) detecte y recoja automáticamente, en el momento en que se produzcan, determinadas interacciones con dicho sistema informático, operaciones realizadas con él o sucesos ocurridos durante su uso, guardando los datos correspondientes a cada uno de ellos, que deberán poder ser consultados desde el propio SIF.Este registro de eventos solo es obligatorio en el caso de los sistemas de emisión de facturas no verificables, no siendo necesario en los casos de SIF «VERI*FACTU».Normativa/Doctrina:• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La normativa al respecto exige a los sistemas informáticos de facturación (SIF) que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos.La remisión inmediata a la Agencia Tributaria de los registros de facturación generados por los SIF VERI*FACTU contribuye decisivamente a cumplir con dichos requisitos. Sin embargo, esto no ocurre en el caso de los sistemas de emisión de facturas no verificables, por lo que entonces es necesario adoptar una medida adicional de seguridad y control consistente en que los sistemas de emisión de facturas no verificables graben de forma inalterable aquellas circunstancias -y sus principales características- que puedan ayudar a conocer con posterioridad cualquier posible anomalía o alteración relacionada con alguno de los requisitos mencionados.Normativa/Doctrina:• Artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Existen al menos los siguientes registros de evento:a. Inicio del funcionamiento del sistema informático como «NO VERI*FACTU».b. Fin del funcionamiento del sistema informático como «NO VERI*FACTU».c. Lanzamiento del proceso de detección de anomalías en los registros de facturación.d. Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación.e. Lanzamiento del proceso de detección de anomalías en los registros de evento.f. Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de evento.g. Restauración de copia de seguridad, cuando esta se gestione desde el propio sistema informático de facturación.h. Exportación de registros de facturación generados en un periodo.i. Exportación de registros de evento generados en un periodo.Además de los anteriores, existe un registro de evento adicional, que es el registro resumen de eventos sucedidos en un determinado periodo (desde que se generó el registro resumen de eventos anterior, o bien desde el inicio de funcionamiento del sistema informático de acuerdo al Reglamento si no se hubiera generado aún ningún registro resumen de eventos anterior). Este registro resumen de eventos se grabará cada 6 horas en las que el SIF haya estado operativo y disponible para su uso, así como antes de cerrarse o apagarse.Por último, el productor (fabricante) del SIF podría voluntariamente registrar otros eventos que considerara de interés al respecto.Normativa/Doctrina:

• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículos 9.1 y 9.2 de la orden por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

En el caso mencionado, el SIF deberá registrar los eventos independientemente para cada OEF, como si fueran SIF distintos. En definitiva, habrá tantos como OEF.Normativa/Doctrina:• Artículos 7.a y 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 2.a de la orden por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

En general, las mismas exigidas a los registros de facturación, es decir, los registros de evento deberán realizarse de tal forma que queden garantizadas sus características de integridad, inalterabilidad, trazabilidad, conservación, accesibilidad y legibilidad, tal y como se exige para los registros de facturación, cumpliendo de forma análoga las especificaciones indicadas para estos últimos.Para más detalle sobre dichas características y requisitos, se recomienda consultar las preguntas frecuentes recogidas en sus correspondientes apartados.Normativa/Doctrina:• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 9.3 de la orden por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

Sí. El sistema informático de facturación (SIF) deberá firmar electrónicamente todos los registros de evento que genere, cumpliendo de forma análoga las especificaciones dadas al respecto para el caso de los registros de facturación.Normativa/Doctrina:• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 9.3 de la orden por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

El plazo de tiempo durante el que se deben guardar los registros de evento generados coincide con el que aplica a los registros de facturación generados en el mismo periodo temporal (ver en el apartado correspondiente la pregunta frecuente equivalente).En cuanto a la responsabilidad de su conservación es también la misma que en el caso de los registros de facturación (ver en el apartado correspondiente la pregunta frecuente equivalente).Normativa/Doctrina:• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.•Artículo 9.3 de la orden por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

No, salvo que la Agencia Tributaria le requiera el envío de los mismos.Normativa/Doctrina:• Artículo 8.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La normativa de este proyecto no detalla el modo en el que puede realizarse el almacenamiento de los registros de facturación. Se admiten diversas soluciones técnicas, siempre que cumplan las funcionalidades requeridas (integridad, posibilidad de exportación, etc.). La apuntada es una posibilidad que parece adecuada ya que debe suponer menos necesidad de conversión.

Cuando sea necesario cambiar algún dato de un registro de facturación de alta ya producido, deberá generarse otro registro que complete, modifique o anule el contenido del anterior, pero no podrá alterarse o manipularse el primer registro de facturación para evitar que la secuencia de facturas se altere.Por lo tanto, no hay acciones permitidas sobre los registros de facturación una vez producidos estos de forma definitiva.Para modificar un “registro de facturación de alta” deberá generarse un nuevo registro de anulación. En este último caso podrá ser una anulación completa del registro inicial o una subsanación / sustitución (es decir sustitución del “registro de alta” por otro registro subsanado). En cualquier caso, la forma de proceder es elaborar nuevos registros de anulación /subsanación y nunca alterar directamente los registros de facturación de alta generados previamente.En el caso de que se pretenda cambiar menciones de la factura que no estén contempladas en el “registro de facturación de alta”, y que, por consiguiente, no determinen alteración en el registro de alta producido, la subsanación no exigirá generar un nuevo registro, pudiendo realizarse directamente.

En las operaciones de los regímenes de ventanilla única (OSS, one stop shop), contempladas en el artículo 166.bis de la Ley del IVA, 37/1992, introducido por Real Decreto Ley 7/2021, el código de régimen a indicar de la lista L8 es el "17": Operación acogida a alguno de los regímenes previstos en el Capítulo XI del Título IX (OSS e IOSS).En cuanto al código de factura a informar de la lista L2, será el que le corresponda a la naturaleza de la factura, según se trate de factura ordinaria/completa ("F1"), simplificada ("F2").

En las facturas existen menciones voluntarias perfectamente válidas, que derivan de prácticas mercantiles o incluso de otra naturaleza, y que, por una parte, no son menciones fiscales obligatorias del artículo 6.1 del Reglamento de Obligaciones de Facturación, aprobado por RD 1619/2012; y por otra, no han sido incluidas como menciones en el registro de facturación, que se regula en el artículo 10 del RRSIF, que aprueba el RD 1007/2023. Como es sabido, el mencionado registro es simplificado. Por lo tanto, los importes suplidos al igual que ocurre con el recargo financiero, no son importes "propios" del registro de facturación, y no tienen que incluirse entre las menciones del “registro de facturación de alta”. No obstante, en el caso de que se incluyeran como mayor importe en el concepto “Importe total factura” (lo cual, no es obligatorio), deberán consignarse como importe no sujeto al IVA o cantidades a tipo cero (0%).Por lo que se refiere a las retenciones, estas no forman parte formalmente del registro de facturación (no es uno de los elementos constitutivos de la factura de acuerdo con la Directiva UE).No obstante lo mencionado en los párrafos anteriores sobre los registros de facturación de alta, nada impide incluir esas u otras menciones en la factura efectivamente emitida e impresa (o remitida electrónicamente) al destinatario, que contendrá toda la información logística, financiera, etc. que sea precisa o conveniente. Pero el extracto de información obligatoria que integra el “registro de facturación de alta” (y que se detalla en el artículo 10 del RRSIF) no contemplará tales datos.

Respecto de los descuentos por pronto pago, la doctrina administrativa puede resumirse así:• El otorgamiento de descuentos y bonificaciones constituye una práctica frecuente dentro del ámbito empresarial como un método para incentivar las ventas. La consecuencia de los mismos, con independencia del tratamiento contable que proceda, es una minoración del precio de adquisición de los correspondientes bienes o servicios.• Estos descuentos y bonificaciones pueden concederse en metálico o en especie. Generalmente, se trata de descuentos por pronto pago, descuentos promocionales (de temporada o estacionales, inicio de una nueva actividad, liquidación, introducción de un nuevo producto, por la condición del adquirente, etc.), descuentos por cantidad relativos a una operación y otros de análogas características.• Los descuentos o bonificaciones no forman parte de la base imponible cuando concurran los requisitos siguientes:a. Que se justifiquen por cualquier medio de prueba admisible en Derecho. Generalmente, el documento que justifica su práctica es la propia factura que documente la operación, sin que sea preciso que tales descuentos y bonificaciones figuren separadamente, si bien debe probarse su existencia, circunstancia particularmente relevante en operaciones vinculadas. Sin embargo, sí que se exige que en la factura consten todos los datos necesarios para la determinación de la base imponible, haciendo mención expresa, en su caso, de cualquier descuento o rebaja que no esté incluido en el precio unitario, concepto que debe figurar siempre en la factura.b. Que se concedan previa o simultáneamente al momento de realización de la operación -el de devengo del impuesto-. Esta es la práctica comercial en este tipo de descuentos, predominando aquellos que se conceden en el momento de realizarse la operación. Cuando los descuentos o bonificaciones se concedan con posterioridad al momento de realizarse la operación también afectan a la base imponible, modificándose a la baja su importe.c. Que se otorguen en función de tal operación.d. Que no sean remuneración de otras operaciones efectuadas por el destinatario de la operación o por un tercero en su nombre, en favor del sujeto pasivo que realiza la operación a la que se pretenda afectar el otorgamiento de los descuentos o bonificaciones.De acuerdo con lo anterior, en la factura debe figurar el descuento por pronto pago cuando se conceda de forma previa o simultánea a la operación.Siendo el registro de alta previo a la factura y a partir del cual se generará la factura, si se desea que quede constancia de dicho descuento, este debe aparecer en el “registro de facturación de alta”. La forma de incluirlo es en una de las líneas del bloque de desglose, sin perjuicio de hacer mención al descuento en el campo “descripción de la operación”.

Se pueden dar varios casos de error, existiendo diferentes posibles soluciones (anulación, facturas rectificativas, etc.), para las cuales el Reglamento prevé registros de facturación de anulación y también, en el registro de facturación de alta, un campo de "tipo factura", en el cual se encontrarían incorporadas diferentes tipos de facturas rectificativas.En concreto por lo que se refiere al “Registro de facturación de anulación”, el artículo 11.2.c y ss del RRSIF exige determinadas menciones que identifican el registro de facturación de alta que se anule.El detalle sobre el modo de codificar este tipo de errores aparecerá regulado en la OM que desarrolla el RRSIF.

Sí. Desde el punto de vista sustantivo, si las facturas se han emitido, aunque sean erróneas deben mantenerse, con su correspondiente numeración, y sin perjuicio de que se anulen posteriormente y se sustituyan por nuevas facturas correctas.Por lo que se refiere a los sistemas de facturación (RRSIF), deberán mantenerse en el sistema los “Registros de facturación de alta”, aunque sean erróneos, y deberá generarse un “registro de facturación de anulación” vinculado al registro de alta anulado. Ambos deberán aparecer en los listados de facturación, a fin de preservar la integridad de la cadena de registros.

Es el resultado de aplicar una función o algoritmo de cálculo de huella a una determinada información (en este caso, a unos datos del registro). Se trata de un dato (habitualmente de mucha menor longitud que la información sobre la que se ha calculado) con la propiedad de que es único para la información origen y a partir de la cual sería “virtualmente imposible” encontrar u obtener otra información alternativa (y menos aún que fuera significativa) cuya huella fuera la misma que la calculada para la información original. Es decir, si se cambiara -por poco que fuera- la información original, la huella de la nueva información modificada también cambiaría y no coincidiría con la huella obtenida para la información original.De ahí su nombre, porque es como si fuera una huella dactilar (“pequeña”) que “identifica” al contenido original (“grande”) sobre el que se obtuvo.

A todos los registros de facturación, de alta y de anulación, generados por el sistema informático de facturación (SIF).Adicionalmente, los sistemas de emisión de facturas no verificables, como están obligados a generar registros de evento, también deberán calcular la huella o «hash» de estos.

La huella o «hash» se calcula solo sobre unos pocos datos relevantes de los registros. Dichos datos son distintos en función del tipo de registro generado (de facturación de alta, de facturación de anulación o de evento) sobre el que se va a calcular la huella o «hash». Se puede consultar cuáles son en el documento “Detalle de las especificaciones técnicas para la generación de la huella o hash de los registros” que se puede encontrar en la web de desarrolladores y en la sede electrónica de la Agencia Tributaria.Finalmente, el resultado de aplicar el algoritmo de cálculo de la huella sobre dichos datos del registro se almacenará en el propio registro como un campo más. Además, dicha huella también deberá incluirse dentro del contenido del registro inmediatamente siguiente que se pueda generar con posterioridad, formando así parte del mecanismo de encadenamiento de registros con el que se implementa el requisito de trazabilidad de los registros.

El algoritmo de cálculo de huella o «hash» a emplear es, por el momento, SHA-256 en todos los casos, es decir, para todos los tipos de registro. Tanto este como otros detalles y ejemplos del procedimiento de cálculo de la huella se pueden consultar en el documento “Detalle de las especificaciones técnicas para la generación de la huella o hash de los registros” que se puede encontrar en la web de desarrolladores y en la sede electrónica de la Agencia Tributaria.

La huella o «hash» de un registro juega un papel fundamental para saber si se ha mantenido la integridad e inalterabilidad de ciertos datos relevantes del registro. Por otro lado, como la huella de un registro ha de incluirse a su vez dentro del contenido del registro inmediatamente siguiente que se pueda generar con posterioridad, también forma parte del mecanismo de encadenamiento de registros con el que se implementa el requisito de trazabilidad de los registros.

Todos los SIF están obligados a calcular y colocar la huella correctamente, encadenando los registros según se exige en las correspondientes especificaciones.Dicho esto, los SIF VERI*FACTU no están obligados a realizar comprobaciones de huellas ni a ofrecer funcionalidades que permitan comprobarlas, ya que remiten todos sus registros de facturación (RF) a la Agencia Tributaria y es esta quien lo puede hacer (y, por este mismo motivo, no están obligados a generar registros de evento).Sin embargo, en el caso de un sistema de emisión de facturas no verificables, este también debe ofrecer como funcionalidad la posibilidad de comprobar las huellas de los registros generados que estén a su alcance. Asimismo, al generar un nuevo registro, debe efectuar obligatoriamente la comprobación del correcto encadenamiento del anterior registro generado, lo que incluye la verificación de que la huella del anterior registro generado es correcta y que la huella encadenada en él (del registro previo al anterior) también es correcta. Esto debe hacerlo tanto para los registros de facturación, de alta y de anulación, como para los registros de evento que genere (se recuerda que los sistemas de emisión de facturas no verificables sí están obligados a generar registros de evento).

No. La huella del RF no forma parte de los datos que se incluyen en el código «QR» tributario añadido a las facturas expedidas por los sistemas informáticos de facturación (SIF) utilizados por los obligados a expedir facturas a los que aplica el reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Se trata de un determinado proceso que, aplicado a cierta información (en este caso, un registro), genera un resultado con el que es posible comprobar a posteriori que el contenido de lo firmado se corresponde con la firma realizada sobre el mismo, así como la autoría de lo firmado, garantizando que ningún otro autor puede haber generado dicha firma, es decir, asegura que el autor de la firma no puede repudiar lo firmado.

No. Los SIF VERI*FACTU no están obligados a firmar electrónicamente los registros generados. Solamente los sistemas de emisión de facturas no verificables están obligados a firmar electrónicamente tanto los registros de facturación, de alta y de anulación, como los registros de evento generados por ellos, de acuerdo a las especificaciones dadas al respecto.

Porque remiten inmediatamente a la Agencia Tributaria los registros de facturación (RF) generados y este proceso de remisión incluye autenticación mediante certificado electrónico cualificado, así como medios de transmisión seguros, por lo que, al remitir de esta manera, se considera que se realiza una firma básica del RF y, por tanto, no es necesario realizar la firma electrónica explícita del RF.

Aunque los SIF VERI*FACTU no están obligados a firmar electrónicamente los RF que generan y remiten a la Agencia Tributaria, si quieren pueden hacerlo y remitirlos firmados electrónicamente. Se recuerda que, en el caso de SIF VERI*FACTU, tampoco están obligados a generar registros de evento (ni, por tanto, a firmarlos).

Los sistemas de emisión de facturas no verificables deben firmar electrónicamente todos los tipos de registros que generen, es decir, tanto los registros de facturación (RF), de alta y de anulación, como los registros de evento.

El tipo de firma electrónica a utilizar en todos los casos (registros de facturación, de alta y de anulación, y registros de evento) será XAdES Enveloped Signature. Tanto este como otros detalles y ejemplos del procedimiento de cálculo de la firma electrónica se pueden consultar en el documento “Especificaciones técnicas para generación de la firma electrónica de los registros de facturación” y en el archivo comprimido “ZIP: Anexos ejemplos firma registros de facturación” que se pueden encontrar en la web de desarrolladores y en la sede electrónica de la Agencia Tributaria.

Junto con la huella y el resto de datos firmados, la firma electrónica permite saber si se ha mantenido la integridad e inalterabilidad del registro firmado, garantizando la autoría de la firma sobre lo firmado (es decir, el no repudio de lo firmado). Por este motivo también contribuye a garantizar la integridad e inalterabilidad del encadenamiento de registros, que es la forma de implementar el requisito de trazabilidad.

Los sistemas de emisión de facturas no verificables deben ofrecer la posibilidad de comprobar de forma rápida, fácil e intuitiva la firma electrónica de los registros de facturación, de alta y de anulación, y de los registros de evento generados que estén a su alcance. La comprobación se hace, en principio, a petición del usuario del sistema de emisión de facturas no verificables (no es obligatorio que sea automática ni que se deba hacer periódicamente).Se recuerda que, como se ha indicado en otras preguntas frecuentes, los SIF VERI*FACTU no están obligados a firmar los registros ni, por tanto, a comprobar firmas.

En el art. 29.2.j de la LGT (introducido por la Ley 11/2021, de 9 de julio, conocida coloquialmente como “Ley Antifraude”) se menciona la posibilidad de que los sistemas y programas informáticos que soporten los procesos de contables, de facturación o de gestión de los empresarios deban estar certificados en la forma que se determine reglamentariamente.Acogiéndose a esta posibilidad, y por lo que se refiere a los sistemas de facturación, en el artículo 13.1 del Reglamento de Requisitos de Sistemas de Facturación ( RRSIF ), aprobado por R. D. 1007/2023, de 5 de diciembre, que integra la Sección 3ª denominada “Certificación de los sistemas informáticos”, se indica que corresponderá a la persona o entidad productora del sistema informático certificar, mediante una declaración responsable, que el sistema informático cumple con lo dispuesto en el artículo 29.2.j de la Ley 58/2003, General Tributaria, así como con lo dispuesto en el citado Reglamento ( RRSIF ) y en las especificaciones que, en su desarrollo, se aprueben mediante orden ministerial.Por lo que se refiere a su formato y sin perjuicio del mayor detalle que aparece en la OM de desarrollo, el artículo 13.2 del RRSIF establece que deberá constar por escrito y de modo visible en el propio sistema informático en cada una de sus versiones, así como para el cliente y el comercializador en el momento de la adquisición del producto.Normativa/Doctrina:• Artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria.• Artículo 13.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

No. Para certificar un producto no se requiere de procesos de certificación realizados por otras personas, entidades u organismos independientes -y, por tanto, ajenos al productor- que se dediquen a este tipo de tareas, sino que se trata de una “autocertificación” del propio productor del producto SIF realizada como Declaración Responsable e incorporada al producto.En cuanto a su previo registro no está previsto en la norma. Para cumplir con la normativa a este respecto no se prevé ningún registro previo del producto SIF por parte de nadie (ni productor, ni comercializador, ni usuario).Normativa/Doctrina:• Artículo 13.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La Certificación mediante Declaración Responsable le corresponde, según lo establecido en el RRSIF al productor (fabricante o desarrollador) de dicho SIF .Por lo que se refiere a los comercializadores (que no sean los fabricantes o productores de los SIF), para no incurrir en la responsabilidad a que se refiere el artículo 201.bis de la LGT, deberán asegurarse de que los productos SIF que comercialicen estén debidamente certificados por sus fabricantes.Normativa/Doctrina:• Artículo 13.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí. La Certificación de un producto SIF es obligatoria y es la forma en que su productor certifica que dicho producto SIF cumple con los requisitos exigidos en la normativa al respecto. De esta forma el usuario puede utilizar ese producto con total tranquilidad.Normativa/Doctrina:• Artículo 13.1 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Sí. Cada versión, por pequeña variación que introduzca, es un producto distinto de los anteriores, con un funcionamiento particular, por lo que es necesario que el productor de dicha versión del SIF certifique expresamente que dicha versión cumple con los requisitos exigidos, emitiendo e incorporando en el producto la correspondiente Declaración Responsable.Normativa/Doctrina:

• Artículo 13.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.4 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

La Certificación por medio de Declaración responsable del SIF deberá ser proporcionada por el productor del mismo en formato legible y estar accesible dentro del propio SIF que se ponga a disposición de los usuarios, es decir, formando parte del propio producto. Además, deberá estar a disposición del cliente y del comercializador en el momento de la adquisición del producto.Por lo tanto, la Certificación deberá estar accesible en dos ubicaciones distintas:Interna al propio SIF que se ponga a disposición de los usuarios, es decir, dentro del mismo producto, formando parte de él. Por lo tanto, un SIF deberá contener la Certificación correspondiente a su versión actual, que será accesible de forma rápida, fácil e intuitiva desde cualquier punto de acceso o terminal conectado a dicho SIF a través del cual se pueda facturar o administrar el SIF. A este respecto, se recomienda que, a ser posible, se ubique en una opción específica dentro de algún menú, como por ejemplo “Ayuda” (en el caso de que exista), al lado de otras opciones similares que suelen existir habitualmente, como “Acerca de”.Externa al propio SIF , de manera que pueda ser accedida de forma directa e independiente del producto para que el comercializador, y el usuario o potencial usuario del SIF puedan ver la misma en cualquier momento (por ejemplo, antes o en el momento de su adquisición) y así asegurarse de que éste cumple la normativa vigente sin necesidad de tener que instalar y poner en funcionamiento el producto para acceder a ella desde dentro del mismo.En este último caso de ubicación externa al SIF , la certificación concreta que corresponde al producto se podrá proporcionar en formato papel o electrónico, bien en soporte físico, como por ejemplo un CD, o siendo accesible a través de Internet, pero siempre en un formato de uso ampliamente extendido y gratuito, como el texto puro, PDF o similar. Ver en otra FAQ las recomendaciones que se dan sobre la gestión de las Declaraciones Responsables en cuanto a su guardado y almacenamiento, ubicación y acceso “externos”.Normativa/Doctrina:• Artículo 13.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.3 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Sí, tanto fabricante como comercializador deben guardar esas certificaciones hechas mediante Declaración Responsable. El productor, para todas las versiones que haya producido y puesto a disposición de los usuarios desde el momento en el que así lo exija la normativa. El comercializador, para todas las que haya comercializado, es decir, para todas las que se hayan producido y puesto a disposición de los usuarios durante el tiempo en el que las ha comercializado, siempre a partir del momento en el que así lo exija la normativa. Tanto el cliente usuario como la Administración tributaria les podrán solicitar las mismas.A este respecto se recomienda que, adicionalmente, todas las certificaciones sean accesibles públicamente y localizables fácilmente a través de Internet, aunque la versión del producto que certifiquen ya no esté disponible para su adquisición, descarga o uso (típicamente por obsolescencia, falta de soporte o similar). Esto, además de cumplir con los requisitos exigidos al respecto, facilitaría tanto su gestión por parte de los productores y comercializadores, como su consulta por parte de los usuarios y de la Administración tributaria, haciendo el proceso más sencillo, ágil y transparente para todos.Normativa/Doctrina:• Artículos 13.2 y 13.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículos 15.2.b y 15.3 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

No. La Certificación que obligatoriamente deberá constar en el propio SIF será la correspondiente a la versión actualmente utilizada, no siendo necesario mantener en el propio SIF las certificaciones de versiones anteriores. Sin embargo, como ya se explica en otra pregunta frecuente, los productores y comercializadores de dichos productos deberán guardar todas las Certificaciones de todas las versiones de sus SIF puestas a disposición de los usuarios desde el momento en el que así lo exija la normativa. De la misma forma, los usuarios de estos Sistemas cuando los sustituyan o actualicen las versiones, deben conservar los certificados de los sistemas que se sustituyan o actualicen a partir de la entrada en aplicación de las obligaciones de la normativa de SIF . Esta conservación puede ser en formato papel o electrónico, bien en soporte físico, como por ejemplo un CD, o siendo accesible a través de Internet.Normativa/Doctrina:• Artículos 13.2 y 13.3 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.3 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Los productores de sistemas y programas informáticos de facturación ( SIF ), además de certificar que el sistema informático cumple con el artículo 29.2.j de la LGT con el contenido del RRSIF , aprobado por R. D. 1007/2023, y con las especificaciones dictadas por medio de OM del Ministerio de Hacienda en desarrollo de los anteriores, deberán incluir:los datos referentes al sistema informático, que permitan identificarlo y saber su tipología, composición y funcionalidades, así como conocer las características de la instalación del mismo.los datos identificativos y de localización del productor del mencionado sistema informático, y la fecha y lugar en que firma la correspondiente certificación mediante declaración responsable.El detalle de estos datos obligatorios se puede ver en el artículo 15 de la OM . Adicionalmente, y para ayudar en la confección de dicha Certificación, en la Sede-e de la AEAT se proporcionarán diversos ejemplos, de manera que puedan servir de modelo a seguir a la hora de elaborarla.Ejemplos de declaraciones responsablesNormativa/Doctrina:Artículo 13.4 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículo 15.1 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre

Los productores de sistemas y programas informáticos de facturación ( SIF ), además de certificar que el sistema informático cumple con el artículo 29.2.j de la LGT con el contenido del RRSIF , aprobado por R. D. 1007/2023, y con las especificaciones dictadas por medio de OM del Ministerio de Hacienda en desarrollo de los anteriores, deberán incluir:a. los datos referentes al sistema informático, que permitan identificarlo y saber su tipología, composición y funcionalidades, así como conocer las características de la instalación del mismo.b. los datos identificativos y de localización del productor del mencionado sistema informático, y la fecha y lugar en que firma la correspondiente certificación mediante declaración responsable.El detalle de estos datos obligatorios se puede ver en el artículo 15 de la OM . Adicionalmente, y para ayudar en la confección de dicha Certificación, en la Sede-e de la AEAT se proporcionarán diversos ejemplos, de manera que puedan servir de modelo a seguir a la hora de elaborarla.Normativa/Doctrina:• Artículo 13.4 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.•Artículo 15.1 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre

Sí. De hecho, cuanta más información precisa se aporte sobre el producto, mejor para todos, ya que el productor será más transparente, lo que podrá generar mayor confianza en los usuarios (clientes del productor), y la Administración tributaria podrá disponer de un conocimiento más completo, lo que puede contribuir a evitar o reducir los requerimientos de información al respecto. En este sentido, en el artículo 15.2 de la OM se recomienda añadir algunos de forma voluntaria.Normativa/Doctrina:• Artículo 13.4 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Para la Certificación realizada mediante Declaración Responsable no se exige una firma electrónica del Productor del programa o sistema. Cuando en el artículo 13.4 se habla de incluir en ella la fecha y lugar en que la firma el productor, no se refiere específicamente a una firma electrónica, sino a la fecha y lugar en que es elaborada y suscrita la Certificación por parte del productor. Dicho de otra forma, es la fecha y el lugar en que se certifica ese producto mediante la Declaración Responsable que va incorporada en él.Normativa/Doctrina:• Artículo 13.4 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.1.m de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Cualquier actuación de un productor de software sobre los programas y sistemas SIF producidos por otro, suponen una alteración o modificación del programa original. Por ejemplo, la realización de desarrollos a medida para personalizar el producto y adaptarlo más y mejor al usuario, lo son. Por lo tanto, las modificaciones, adaptaciones o ampliaciones -hardware, software o combinación de ambas- de un sistema informático de facturación producidas por un tercer productor distinto al productor del SIF original no están cubiertas por la certificación del productor del SIF original, por lo que, adicionalmente, es necesario que incorporen su propia certificación realizada por dicho tercer productor.A este respecto, por ejemplo, si la ampliación es realizada por el usuario del SIF con sus propios medios (personal propio y/o personal especializado contratado o subcontratado al efecto dependiente del usuario), el responsable de la ampliación será el usuario del SIF , que como productor de la misma deberá certificarla suscribiendo su correspondiente Declaración Responsable y cumpliendo con todos los requisitos exigidos para la misma. Sin embargo, si el usuario del SIF contrata esa ampliación, como un producto, a una tercera persona o entidad productora, que se encargará de realizarla y entregarla al usuario, será dicho tercer productor quien la deba certificarla cumpliendo con todos los requisitos exigidos para la misma. Es decir, en éste último caso el usuario está adquiriendo un nuevo producto (o componente) de facturación a un tercer productor.Normativa/Doctrina:• Artículos 13.1 y 13.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.4 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Se deberá suscribir y proporcionar un Certificado por cada productor y producto distinto, considerando como producto tanto a un SIF como a una ampliación de un SIF , en ambos casos para cada una de sus versiones. Es decir, habrá tantos certificados como productores distintos, tal y como sucedería si todos ellos solo aportaran un producto, cada uno con una única versión.No obstante, en el caso de que las certificaciones (mediante Declaración Responsable) de las ampliaciones posteriores contengan todos los datos a incluir, referidos en el RSSIF , y abarquen los datos referentes al sistema informático, tipología, composición y funcionalidades, así como conocer las características de la instalación última del mismo, incluyendo el sistema previo y las sucesivas ampliaciones, bastará con disponer de la Certificación de la última instalación que contenga dichas referencias.Normativa/Doctrina:• Artículos 13.1 y 13.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículo 15.4 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

La letra a) se refiere al nombre que el productor ha dado a su propio producto y típicamente será la denominación genérica como se da a conocer de cara a su distribución o comercialización. En los diseños de registro que figuran en el Anexo I de la OM se le denomina “NombreSistemaInformatico” y se incluye una breve descripción, junto con su formato.Por su parte, la letra b) se refiere a un código que ha de establecer también el productor del SIF para identificar de forma única y abreviada a dicho producto de cara a la AEAT , y que también habrá de rellenarse en los registros de facturación, siempre cumpliendo el formato dado en los correspondientes diseños de registro que figuran en el Anexo I de la OM . En dicho anexo se le denomina “IdSistemaInformatico” y se incluye una breve descripción.Este código no se podrá repetir en otro SIF distinto del mismo productor (aunque sí podría darse la coincidencia de que dos productores distintos utilizarán el mismo código para referirse a sus respectivos SIF : por ejemplo, un productor con NIF A9999999A, podría establecer el código “S1” para uno de sus SIF , y un productor con NIF B8888888B, podría también establecer el código “S1” para uno de sus SIF ).Ver en la Sede-e de la AEAT los ejemplos dados al respecto.Normativa/Doctrina:• Artículos 15.1.a, 15.1.b y anexo I de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Con tal de respetar el formato que se especifica en el Anexo I de la OM (para el que solo se admiten dos posiciones, cada una de las cuales deberá ser una letra mayúscula (-excepto la Ñ- o un dígito numérico), el fabricante o productor puede poner lo que le parezca oportuno, pero una vez establecidos han de mantenerse en adelante y no deben repetirse entre los distintos SIF que produzca.Por ejemplo, para los 3 nombres del ejemplo, que deberían consignarse expresa y completamente en los correspondientes Certificados, podría establecer en los registros de facturación, respectivamente, los 3 códigos: XB, XS y XE. O cualesquiera otros: X1, X2 y X3; F1, F2 y F3…Ver en la Sede-e de la AEAT los ejemplos dados al respecto.Normativa/Doctrina:• Artículos 15.1.b) y anexo I de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Se deben indicar todas las versiones de los componentes que conforman el SIF , con la denominación exacta (números, letras, caracteres especiales…) que les dé el productor, en el formato indicado en el Anexo I de la OM. Se puede empezar por el software y continuar con el hardware.Ver en la Sede-e de la AEAT los ejemplos dados al respecto.Normativa/Doctrina:

Artículos 15.1.c y anexo I de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

En ese caso, dado que dicho SIF solo puede funcionar, siempre y exclusivamente, como sistema VERI*FACTU (es decir, no permite la posibilidad de no remitir automáticamente todos los registros de facturación a la AEAT ), deberá indicar una “S” tanto en la Certificación (letra e) como en el campo correspondiente (“TipoUsoPosibleSolo VERI*FACTU ”) dentro de los registros de facturación generados.Normativa/Doctrina:

Artículos 15.1.e y anexo I de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Todo aquel SIF que no esté diseñado y producido para funcionar, siempre y exclusivamente, como sistema VERI*FACTU , independientemente de si luego el usuario lo llegara a utilizar como sistema VERI*FACTU o no, deberá indicar una “N” tanto en la Certificación (letra e) como en el campo correspondiente (“TipoUsoPosibleSolo VERI*FACTU”) dentro de los registros de facturación generados.Normativa/Doctrina:

Artículos 15.1.e y anexo I de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Al tratarse de una ampliación de utilidades del SIF, pero que no afectan ni alteran los requisitos obligatorios regulados en el Reglamento y la Orden Ministerial, ese segundo fabricante no estaría obligado a certificar el producto, por lo que no procede completar lo establecido en el artículo citado del Reglamento.Por el contrario, si la ampliación/modificación es alguna funcionalidad que implementa requisitos obligatorios de seguridad y control exigidos por el reglamento a los SIF , sobre todo los referidos a la generación y firma/grabación o remisión de los registros de facturación (RF), lo que incluiría -por contenerlos como datos que forman parte del RF- el cálculo de la huella y la trazabilidad, la certificación será obligatoria. En este último caso, si la ampliación no afecta a la remisión de registros de facturación, deberá indicar una “N” en la Certificación (letra 1.e), en otro caso deberá indicar una “S” en la misma.Normativa/Doctrina:Artículos 15.1.e de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Dado que se trata de una ampliación de un SIF hecha por un tercer productor distinto del original que produjo el SIF y que el objeto de dicha ampliación es limitado y no afecta a las capacidades originales de uso del SIF exclusivamente por un solo obligado tributario o por varios obligados tributarios para la llevanza de sus respectivas facturaciones, deberá indicar una “N” en la DR (letra 1.f).Normativa/Doctrina:

Artículo 7.a del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículos 15.1.f de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

El Reglamento RSSIF y la Orden Ministerial de desarrollo no dicen nada sobre ese tipo de medidas concretas relacionadas con las posibles BBDD empleadas, que pueden tener muy diferentes características y formas de gestionar su seguridad, sino que se centran en las medidas mínimas que debe cumplir el SIF para implementar los requisitos exigidos. Con ellas, debe ser posible asegurar que no se pueda alterar la realidad facturada, se considera que el sistema debe detectar el intento de efectuar cambios e impedirlos. En cualquier caso, nada impide al fabricante y a su SIF tomar más medidas y, de hecho, toda medida adicional que el fabricante y el SIF adopten, tendente a garantizar o robustecer esos requisitos exigidos, siempre es bienvenida. En cualquier caso, las restricciones no deben suponer una merma de utilidades para el usuario en la realización de cualquier tipo de tareas lícitas como las copias mencionadas.

Será uno de los de modelos que se publicarán en Sede Electrónica.

En un caso como el descrito en la pregunta, hay que definir qué implica cada componente y cuál es su funcionalidad dentro del conjunto. Si tiene impacto en el cumplimiento del Reglamento por parte del Sistema Informático de Facturación, lo lógico es que haya tantos Certificaciones como componentes afectan al cumplimiento del Reglamento RSIF . Todas ellas deberán hallarse disponibles para el usuario del sistema.

Pasados los periodos transitorios contenidos en la Disposición Adicional Cuarta del R. D. 1007/2023, los productores o fabricantes deberán proveer a sus clientes de programas SIF adaptados a la norma. No obstante, si un cliente no quiere adaptar sus sistemas adquiridos con anterioridad, el fabricante o productor queda exento de toda responsabilidad, respondiendo el cliente en los términos del artículo 201.bis LGT en su redacción por Ley 11/2021, de 9 de julio.Un fabricante, con carácter general, deberá dar soporte solo a sistemas de facturación adaptados a la norma, ya que desde el fin de los periodos transitorios, el resto de sistemas dejarán de ser lícitos. Lo anterior se entiende sin perjuicio del soporte necesario para adaptar dichos sistemas.

La diligencia con la que todo productor, fabricante, desarrollador o implementador debe cumplir con la normativa vigente, a la cual se ha comprometido emitiendo la correspondiente Certificación (mediante su declaración responsable), le obliga a adoptar cuantas medidas estén técnicamente disponibles para que la seguridad del SIF (preservando los registros de facturación) no se rompa.Conviene recalcar que si el software opera en modo VERI*FACTU (con remisión voluntaria inmediata de los registros), es más improbable que el usuario pueda llevar a cabo ninguna alteración de los registros u otra acción irregular (ya sea voluntaria o involuntariamente) “a posteriori”, pues los registros de facturación constarán en la AEAT , lo que impide realizar cambios sobre ellos.

Sí, la obligación de certificación se aplica a todos los SIF .

La Ley 11/2021, de 9 de julio, ha introducido el nuevo artículo 29.2.j de la Ley General Tributaria en el que se establece que cualquier programa de contabilidad, facturación o gestión de los empresarios debe respetar los requisitos de garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Esa genérica obligación, para el caso de los Sistemas de Facturación, en función de su importancia desde el punto de vista del cumplimiento tributario, se ha materializado en ciertas obligaciones reguladas por Real Decreto 1007/2023, de 5 de diciembre que aprueba el RRSIF. Este Reglamento de requisitos de los sistemas informáticos de facturación es el que obliga, desde la entrada en vigor de sus disposiciones, a que todos los programas y sistemas informáticos de facturación (SIF) correspondientes a los empresarios y operaciones del ámbito subjetivo y objetivo de la norma, deban estar Certificados.Por lo tanto, la obligación de certificación a la que se refiere el artículo 13 del RRSIF, no abarca a todos los fabricantes de software, ni a todos los programas, sino exclusivamente a los fabricantes de Sistemas Informáticos de Facturación y en relación con dichos sistemas.

No, el hardware genérico -ordenador- sobre el que se instala un software informático de facturación no hay que certificarlo. Lo más frecuente será que se deba certificar el programa o sistema mismo, es decir el código instalado en el hardware.Evidentemente, todo software ha de ejecutarse en un hardware. Pero la mención al hardware contenida en el artículo solo se refiere a aquellos supuestos en los que el hardware del sistema SIF forme parte de un "todo" que se ofrece (comercializa) como producto completo (software y hardware) para dar soporte a la facturación, o bien cuando se trate de algún hardware específico que realiza o interviene de forma relevante en el cumplimiento de algún requisito exigidos al SIF

La empresa que efectúe la programación del código o integre partes de otro software, ya sea o no de código abierto, debe realizar la declaración responsable, incorporar los datos obligatorios e indicar qué componentes utiliza. En el caso de que utilice código abierto, se hará responsable del funcionamiento del mismo, incluyendo los sistemas de seguridad exigidos para preservar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros.

Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo, cumpliendo para ello lo que establece el mencionado artículo 13 y su normativa de desarrollo.

Cualquier operación sobre los registros de facturación, sea VERI*FACTU o no, debe ser registrada a través de un registro de facturación, por lo que el acceso desde el SIF a modificaciones directamente sobre la base de datos de registros ya emitidos no debe ser una operativa permitida.Si el SIF opera en modalidad VERI*FACTU (con remisión voluntaria inmediata de los registros), es más improbable que el usuario pueda llevar a cabo ningún acceso u otras actuaciones indebidas “a posteriori”, pues los registros originales de facturación ya constarán en la AEAT , lo que impide realizar cambios sobre ellos. En este sentido, el acceso a las bases de datos de registros de facturación ya remitidos a la Sede Electrónica carece de los mismos riesgos que si el sistema fuera de conservación en local de los registros y los sistemas de seguridad no tienen por qué ser igual de rigurosos.Conviene recalcar que si el software opera en modo VERI*FACTU (con remisión voluntaria inmediata de los registros), es más improbable que el usuario pueda llevar a cabo ninguna alteración de registros u otra acción irregular “a posteriori” (ya sea de forma voluntaria o por error), pues los registros de facturación constarán en la AEAT, lo que impide realizar cambios sobre ellos.

En un caso como el descrito la responsabilidad no recae en el fabricante, sino que recaería en su integridad en el usuario, en la medida que no haya adaptado sus sistemas a la normativa vigente.

Los SIF comercializados pueden ser “SOLO VERI*FACTU " (es decir que solo permiten su uso como VERI*FACTU ) o "duales" (que permiten ser usados, a elección, como VERI*FACTU y como sistema de emisión de facturas no verificables) y es el cliente (usuario del SIF ) quien elige el modo de funcionamiento. No puede existir un SIF que únicamente funcione como sistema de emisión de facturas no verificables, porque el Reglamento obliga a que todos los SIF tenga la capacidad de ser VERI*FACTU (aunque luego el usuario no elija esa modalidad de funcionamiento).La responsabilidad en este aspecto del productor de sistemas "duales" es asegurarse del cumplimiento de la normativa (Ley, Reglamento y OM ), de modo que se garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros.

El artículo 29.2.j de la Ley General Tributaria, establece la obligación, por parte de los productores, comercializadores y usuarios, de que los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas, garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Reglamentariamente se podrán establecer especificaciones técnicas que deban reunir dichos sistemas y programas, así como la obligación de que los mismos estén debidamente certificados y utilicen formatos estándar para su legibilidad.Los contribuyentes incluidos en el SII aparecen expresamente excluidos del desarrollo reglamentario aprobado por RD 1007/2023, de 5 de diciembre, que aprueba el Reglamento que regula los Sistemas Informáticos de Facturación (RRSIF). Así consta expresamente en el artículo 3.3 del citado Reglamento que establece:El presente Reglamento no se aplicará a los contribuyentes que lleven los libros registros en los términos establecidos en el apartado 6 del artículo 62 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el Real Decreto 1624/1992, de 29 de diciembre.Por lo tanto, no existiendo, en relación con los obligados adscritos al SII, el desarrollo reglamentario al que se alude en el artículo 29.2.j de la LGT, debe entenderse que no le es de aplicación la obligación de certificar sus sistemas. Todo ello sin perjuicio de que queden genéricamente obligados a garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros que generen.

Para el cumplimiento de las obligaciones previstas en el Reglamento que regula los requisitos de los sistemas de facturación (RRSIF), aprobado por RD 1007/2023, de 5 de diciembre, se admiten dos modalidades: VERI*FACTU (sistemas de emisión de facturas verificables) y sistemas de emisión de facturas no verificables.Adicionalmente, de acuerdo con el artículo 7.b del RRSIF aprobado por RD 1007/2023, de 5 de diciembre También, la Administración Tributaria, diseñará un aplicativo web de último recurso, que tendrá la condición de VERI*FACTU y lo pondrá a disposición de los empresarios que carezcan de SIF , en cuyo caso también se cumplirán los requisitos del RRSIF .Normativa/Doctrina:

Artículos 7 y 15 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La respuesta a esta pregunta se encuentra en los artículos 15 y 16 del Reglamento, donde se mencionan a su vez los artículos 7, 8.2 y 14.2.De forma resumida, la diferencia clave está en que los SIF «VERI*FACTU» remiten en línea -a través de una conexión a Internet, de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente- a la Agencia Tributaria todos los registros de facturación correspondientes a las facturas expedidas por el SIF, mientras que un sistema de emisión de facturas no verificables no los remite, sino que los almacena obligándose a garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos durante todo el periodo de prescripción fiscal.La remisión en línea por parte de los SIF «VERI*FACTU» es una forma de cumplir con el Reglamento que hace innecesaria la implementación -más complicada y costosa- de otras características de seguridad, a la vez que exime de responsabilidades de conservación y custodia de los registros a los usuarios de los mismos. Por su parte, para cumplir con los requisitos del Reglamento, los sistemas de emisión de facturas no verificables deben incorporar adicionalmente otras medidas de control, entre las que destacan el registro de eventos, la firma electrónica de los registros de facturación y de evento, permitir la posibilidad de exportación de los registros de facturación y de eventos, ofrecer la comprobación de varios requisitos (huella, firma, encadenamiento…) de los registros de facturación y de evento, gestionar alarmas, etc.Normativa/Doctrina:Artículos 7.b, 8.2, 14.2, 15 y 16 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La opción se entenderá realizada de forma tácita por el hecho de iniciar sistemáticamente la remisión de registros de facturación a la sede electrónica de la AEAT . Esta opción se prolongará, al menos, hasta el fin del año natural en el que se haya producido, de forma efectiva, el primer envío voluntario de los registros de facturación.Normativa/Doctrina:Artículo 16.5 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículo 17 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

Una empresa se puede adherir a VERI*FACTU cuando desee. Una vez adherida a esta modalidad, deberá permanecer al menos hasta finalizar el año natural.Si se inicia el año como sistema de emisión de facturas no verificables, en cualquier momento podrá cambiar a VERI*FACTU debiendo permanecer en esta modalidad, como mínimo, hasta el fin del año natural.Normativa/Doctrina:

Artículos 15 y 16.5 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Artículo 17 de la Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

No, la obligación de confeccionar los Libros Registro de Facturas Emitidas (regulada en el artículo 63 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el RD 1624/1992, de 29 de diciembre) se mantiene, al tratarse de una obligación diferente y autónoma de la establecida por el Reglamento SIF , que regula la forma en que deben funcionar los sistemas informáticos de facturación en la emisión y conservación de los registros de facturación de alta o anulación de facturas.Tampoco se exonera de la presentación de modelos informativos como los mencionados, sin perjuicio de la agilización que pueda derivarse de la asistencia para la confección de las mismas.

Sí, los fabricantes de Sistemas Informáticos de Facturación pueden ofrecer aplicaciones solo VERI*FACTU (sistemas de emisión de facturas verificables), aplicaciones “duales” que permitan al usuario optar por VERI*FACTU y por sistemas de emisión de facturas no verificables, o incluso aplicaciones “triples” que permitan lo anterior y, en su caso, utilizarlo en la modalidad de SII .Por el contrario, no se admite la producción de sistemas que únicamente emiten facturas no verificables ya que el RRSIF aprobado por RD 1007/2023, en su artículo 8.1 párrafo segundo, exige a los sistemas tener la capacidad de remisión.En cualquier caso, la decisión de fabricar y comercializar unos u otros sistemas corresponde a los mismos fabricantes en función de necesidades comerciales, ya que la norma no obliga a fabricar sistemas con opción.Normativa/Doctrina:

Artículos 8.1, 15 y 16 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre

En casos excepcionales como los mencionados, u otros análogos, se ampliarían los plazos de remisión hasta la restauración de la caída o el restablecimiento de servicio. En la Orden Ministerial que desarrolla el Reglamento aprobado por el RD 1007/2023 se dan más detalles de cómo proceder al respecto (reenvíos periódicos, marca de “Incidencia” en la cabecera del envío de Registros, etc).En estos casos de incidencias, no hay establecido un plazo máximo fijo para el envío que deberá reintentarse periódicamente hasta que se subsane le incidencia incorporando en el envío la "S" en el campo “Incidencia”.Incidencias como las mencionada, que afectan a la remisión a la AEAT , NO suponen en ningún caso que deba interrumpirse la facturación de la empresa. Esta deberá continuar con normalidad y los sistemas podrán enviar los registros “a posteriori” (reintentando la remisión periódicamente tal como se expone en los párrafos anteriores). Evidentemente si el corte es de energía eléctrica y los sistemas no pueden operar, la decisión de seguir operando/facturando corresponderá al empresario, pero en tal caso la información e facturación deberá recuperarse y remitirse cuanto antes.

Cada usuario debe tener sus Sistemas Informáticos de Facturación adaptados a la normativa que los regula. Pero ello no significa que deba tener solo un único SIF. Es lícito disponer de varios SIF, especialmente cuando las necesidades empresariales así lo justifiquen (varios centros de negocio no interconectados, varias líneas de producto diferenciadas, etc.). En este caso, los SIF deberán cumplir con la normativa, pero la opción por una u otra modalidad no es conjunta para el obligado a facturar, que podrá tener un SIF en la modalidad VERI*FACTU y otro en modalidad sistema de emisión de facturas no verificables. Debe entenderse que cada uno de esos sistemas NO podrá intercalar operaciones en la otra modalidad, es decir, el sistema VERI*FACTU siempre actuará como tal (siempre con envío) y el sistema de emisión de facturas no verificables siempre actuará como tal (siempre con conservación segura de los registros).Debe tenerse en cuenta a este respecto que parte de los beneficios que derivan del uso de soluciones de tipo VERI*FACTU no se puede producir para aquellos obligados tributarios que no tengan TODAS sus operaciones en esta modalidad (por ejemplo, servicios de asistencia como la descarga de registros, precursor del libro registro, menores requerimientos…).Normativa/Doctrina>:

Artículos 7, 15 y 16 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre.

La modalidad VERI*FACTU no contempla como requisito la firma electrónica de los registros de facturación a remitir, ni dicha firma constituye campo obligatorio de la estructura del registro de alta de facturación. Precisamente, una de las ventajas de utilizar VERI*FACTU es la ausencia de esta obligación.Por el contrario, sí será obligatorio en el caso de que el envío de los tiques haya sido a raíz de un requerimiento y/o en el caso de almacenarlas en el propio SIF (sistema de facturación) al no hacer uso de VERI*FACTU.Normativa/Doctrina:Artículo 16 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La pertenencia de todos los módulos señalados al mismo ERP, hacen suponer la interconexión de dichos módulos en un sistema de facturación centralizado (o al menos consolidado y controlado de forma central). En ese caso, todos los registros deberán ser encadenados en el único SIF con un único encadenamiento, independientemente de la serie o número que tengan las facturas a las que corresponden.No obstante, si se tratase de módulos inconexos o parcialmente inconexos, por ejemplo, porque generen la lógica obligatoria (registros de facturación de alta, códigos QR, etc.) de forma descentralizada y sin enlazar en tiempo real o ser controlados por el único ERP (al que le remiten los registros una vez al mes), puede entenderse que son SIF diferentes unos de otros. En este caso, el encadenamiento (y en su caso, el envío) se produce por cada SIF que tiene un funcionamiento aislado de los demás y, por lo tanto, no conoce lo que realiza otro módulo. En este caso cada uno de los SIF deberá cumplir individualmente los requisitos del RRSIF aprobado por RD 1007/2023, de 5 de diciembre.

De entrada, hay que decir que para los productores de SIF , los SIF «VERI*FACTU» resultan más sencillos de producir que los sistemas de emisión de facturas no verificables, ya que tienen bastantes menos requisitos técnicos y de seguridad que implementar.En cuanto a su utilización por parte del obligado a expedir facturas, las principales ventajas de emplear SIF «VERI*FACTU» en lugar de sistemas de emisión de facturas no verificables son las siguientes:

1. Se les exime de la responsabilidad -y, en su caso, de realizar las propias tareas- de almacenar y/o exportar y conservar accesibles y legibles durante años los registros de facturación y los registros de evento. Por lo tanto, su uso puede resultar más sencillo, a la vez que aporta mayor tranquilidad en cuanto al cumplimiento.

1. Derivado del punto anterior, no deberán preocuparse de que le lleguen requerimientos de la Agencia Tributaria para que entreguen posteriormente registros de facturación de sus facturas expedidas con SIF «VERI*FACTU», con el consiguiente ahorro en tiempo y costes de todo tipo (de personal especializado, económico…) vinculados a la tramitación necesaria para el cumplimiento de este tipo de gestiones. Indirectamente ello puede acelerar la tramitación de devoluciones fiscales que se soliciten.

1. No estarán obligados a asegurar que, en todo momento, el reloj empleado por el SIF para datar los registros de facturación y de evento tiene la hora exacta (con un margen de error de un minuto).

1. Mediante los códigos «QR» que se incorporan a las facturas (incluyendo las facturas simplificadas), en las que además también aparecerá la frase “Factura verificable en la sede electrónica de la AEAT ” o “VERI*FACTU”), sus clientes podrán comprobar que esas facturas han quedado registradas en la Agencia Tributaria, lo que supone una garantía de transparencia y calidad en el grado de cumplimiento tributario. Este aspecto podría ser publicitado y argumentado como un elemento distintivo de “calidad y cumplimiento fiscal”.

1. Dispondrán de servicios electrónicos proporcionados por la Agencia Tributaria que les faciliten la presentación de los libros registros de facturas expedidas, completándolos a partir de la información que ya se suministró al remitir los registros de facturación, así como ayudas en la confección de las autoliquidaciones.

Normativa/Doctrina:Diversos artículos del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La fecha de expedición de la factura debe coincidir con la de generación del registro de facturación. Ambas fechas, generalmente deben corresponderse con la fecha en que se remite el Registro de facturación. No obstante, se pueden dar situaciones puntuales de no coincidencia, de la fecha de generación del registro con la de envío (por ejemplo, incidencia al remitir que obliga a reintentar más adelante, cambio de horario de verano/invierno...).Un mayor detalle puede encontrarse en las reglas de validación que afecten a los campos del registro de facturación y del mensaje de remisión a la AEAT .

Si no se obtiene una respuesta tras un envío, se deben remitir de nuevo los registros de facturación hasta obtenerla.Debe recalcarse que estos “envíos” y “respuestas” corresponden a comunicaciones de máquina a máquina, que son gestionados por los SIF y por la sede electrónica de la AEAT , por lo tanto, en general, son transparentes para los usuarios.Normativa/Doctrina:Orden Ministerial por la que se desarrollan las especificaciones técnicas, funcionales y de contenido referidas en el reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el real decreto 1007/2023, de 5 de diciembre, y en el artículo 6.5 del reglamento por el que se regulan las obligaciones de facturación, aprobado por el real decreto 1619/2012, de 30 de noviembre

Para el envío de los Registros de facturación se puede utilizar cualquiera de las vías actuales de identificación admitidas por la AEAT , incluyendo la representación, el apoderamiento y la colaboración social, haciendo uso de un certificado cualificado por parte del tercero que ostente la condición de representante, apoderado o colaborador social.

Sí, la AEAT tiene previsto poner operativo un servicio que permita la descarga de la totalidad de los registros de facturación emitidos por un obligado tributario y comunicados por medio del sistema VERI*FACTU. Igualmente se prevé la descarga de los registros emitidos por los proveedores de ese mismo obligado tributario en la medida que también sean VERI*FACTU.

Todos los registros de facturación que se envíen en un mismo lote deben corresponder al mismo obligado tributario. En el caso de que el mismo SIF dé servicio a múltiples empresas, el sistema deberá realizar envíos separados.

La forma en que el cliente recibe la factura emitida por un SIF, no tiene ninguna diferencia respecto a las emitidas por otros sistemas; esto es, se regula por el Reglamento por el que se regulan las obligaciones de facturación, aprobado por Real Decreto 1619/2012. Así, quien la recibe de otros empresarios o profesionales por las operaciones de las que sean destinatarios y que se efectúen en desarrollo de la citada actividad, así como otras personas y entidades que no tengan la condición de empresarios o profesionales están obligadas a conservarlas (Artículos 1, y 19 a 23). La forma en que se puede expedir y recibir la factura dependerá de que sea facturación en papel o electrónica, y en este caso si es estructurada o no estructurada. EL RRSIF no limita las anteriores posibilidades en modo alguno.Por otro lado, si la pregunta se refiere a los registros de facturación (de las facturas):La AEAT ofrecerá servicios que permitan descargar los registros de facturación a quien los remitió.Asimismo, la AEAT ofrecerá servicios que permitan descargarlos al destinatario (obviamente, solo aquellos registros de facturación que sus proveedores hayan remitido a la AEAT mediante SIF VERI*FACTU).Por último, el receptor de la factura podrá cotejar con el QR la constancia del registro de facturación en la sede electrónica de la AEAT y, en su caso, la coincidencia de la información remitida por el SIF del proveedor

El artículo 29.2.j de la Ley General Tributaria aplica a los sistemas informáticos utilizados para dar soporte a los procesos contables, de facturación y de gestión, por lo que todos ellos están obligados a garantizar los 6 requisitos exigidos sobre los registros empleados (es decir, sobre la información y datos que maneja cada uno) y, por tanto, no permitir interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos.Sin embargo, dicho mandato es genérico para todos los aplicativos salvo en el caso de los Sistemas de Facturación. Para ellos se concreta cómo cumplir con este mandato, lo cual se hace mediante el Reglamento que regula los Requisitos de los Sistemas de Facturación (RRSIF) aprobado por el RD 1007/2023, de 5 de diciembre, que desarrolla los requisitos que se deben implementar en los sistemas informáticos de facturación para cumplir con el artículo 29.2.j de la LGT .Normativa/Doctrina:Artículo 29.2.j de la Ley General Tributaria Ley 58/2003, de 17 de diciembre, introducido por Ley 11/2021, de 9 de julio.

La inmediatez del envío a VERI*FACTU es parte del sistema de seguridad de los registros de facturación, por lo que se aplica en todos los casos. Por otro lado, el contraste de la operación por el cliente utilizando el código QR, característico de los sistemas VERI*FACTU, solo puede realizarse si el envío se produce con inmediatez. Por lo tanto, el envío de las facturas simplificadas debe producirse en un caso como el mencionado de forma inmediata, respetando los tiempos técnicos exigidos por el control de flujo de información que la Sede Electrónica establezca.Normativa/Doctrina:Artículos 15 y 16 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación ( RRSIF ), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

Los citados artículos del Reglamento de Obligaciones de Facturación se refieren a los sistemas informáticos del artículo 7 del Reglamento aprobado por R. D. 1007/23 (esto es, el Reglamento RSSIF). A su vez, el artículo 3.3 del Reglamento SIF , excluye del ámbito subjetivo de este a los obligados al SII (Suministro Inmediato de Información). Por lo tanto, dichos nuevos requisitos incorporados a los artículos 6.5 y 7.5 del Reglamento de Obligaciones de Facturación (ROF) aprobado por RD 1619/2012, solo son obligatorios para aquellos empresarios y profesionales obligados NO sujetos al SII, cuando deban expedir facturas. En particular las expresiones “VERI*FACTU” o “Factura verificable en la sede electrónica de la AEAT” incluidas en las facturas impresas emitidas solo serán obligatorias para los SIF de los citados empresarios que opten por funcionar de acuerdo a esta modalidad.Los obligados al SII, a todos los efectos relativos a su facturación propia, no quedan afectados por el R. D. 1007/2023.

Efectivamente, todas las facturas producidas con un SIF, cualquiera que sea la modalidad empleada, deberán llevar obligatoriamente el código «QR» impreso. Esa obligatoriedad deriva de la redacción de la Disposición final primera del Real Decreto 1007/2023, en relación con el artículo 17 del Reglamento SIF aprobado por dicho Real Decreto.En cuanto a la finalidad del código «QR», a través de este no se envía la factura a la AEAT por su emisor, sino que sirve:

1. Para que el cliente destinatario de la factura pueda cotejar o comprobar si el correspondiente registro de facturación se encuentra en poder de la AEAT o no. Este cotejo tendrá lugar cuando se utiliza un sistema de emisión de facturas verificables (sistema VERI*FACTU).

1. Por el contrario, cuando el sistema informático de facturación empleado es un sistema de emisión de facturas no verificables, la remisión de la información a la Administración Tributaria por el cliente destinatario de la factura, por medio del código QR, sirve para dejar constancia de la existencia de la factura misma y su contenido esencial, lo cual podría servir para un posible contraste futuro por parte de la AEAT.

En general el «QR» contribuye a permitir un mejor control del cumplimiento tributario del emisor de la factura, es decir, es una forma de mostrar una mayor "fiabilidad" fiscal (si la factura está registrada en la AEAT , el cliente puede esperar que su proveedor no está realizando ningún tipo de fraude fiscal, ni le está repercutiendo un IVA que luego no declara).Normativa/Doctrina:Artículo 17 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

La respuesta que recibirá el empresario o consumidor final, receptor de la factura, dependerá de si se han utilizado o no sistemas «VERI*FACTU» para expedir la factura.Si la factura ha sido generada a través de un sistema «VERI*FACTU», la AEAT procederá a cotejar la información recibida con los registros de facturación remitidos por el expedidor de la factura. Las respuestas dadas a peticiones realizadas a través del código «QR» por un sistema «VERI*FACTU» serán las siguientes:

1. Factura encontrada. En la Agencia Tributaria consta una factura con idénticas características a la remitida.
2. Factura no encontrada. En la Agencia Tributaria no consta ninguna factura con las características remitidas.

Si la factura ha sido generada a través de un sistema de emisión de facturas no verificables, la AEAT no puede realizar un cotejo con los registros de facturación porque estos no han sido enviados previamente por el expedidor de la factura. En este caso, el mensaje de respuesta es “Factura no verificable”. Esta factura ha sido expedida por un sistema informático de facturación que NO es «VERI*FACTU», (es decir, que no envía información de la factura a la Agencia Tributaria), por lo que no se puede verificar, si bien esa información puede servir de ayuda a la Agencia Tributaria en el desempeño de sus tareas de control del cumplimiento tributario.

Para el caso de que se utilice facturación electrónica estructurada, al no existir impresión en papel, el código QR no podrá incorporarse como tal a la factura. No obstante, la obligación de incorporar la información del QR, para el caso de facturación electrónica, ya sea la factura completa o simplificada, se sustituye por la incorporación a las e-Facturas del contenido del QR, incluyendo la url de cotejo en sede de la factura. Así lo establece el artículo 6.5.a del Reglamento de Obligaciones de Facturación al disponer que En el caso de que la factura sea electrónica, la representación gráfica podrá ser sustituida por el contenido que representa el código “QR”.Por ello los clientes que reciban facturas electrónicas estructuradas podrán utilizar la información contenida en la factura electrónica para, a través de la URL recibida (la misma que codificaría el QR), acceder al servicio de verificación de factura igual que si escanearan el código QR.Si la factura electrónica no es estructurada, sino que simplemente se transmite en formato electrónico visible (PDF, TIF, etc) e imprimible, la incorporación del QR no tendrá especialidades respecto de la que corresponde a la emisión en papel.Normativa/Doctrina:• Artículo 6.5.a del Reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre, en la redacción que le da el RD 1007/2023, de 5 de diciembre.• Artículo 17 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre y su desarrollo por Orden Ministerial.

No. El código «QR» tributario solo se añade a las facturas -sean «completas u ordinarias» o simplificadas, sean en papel o electrónicas- expedidas por los sistemas informáticos de facturación afectados por el RRSIF .Normativa/Doctrina:

• Artículos 1.1 y 1.2 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.• Artículos 6.5 y 7.5 del reglamento por el que se regulan las obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, de 30 de noviembre, introducidos por la disposición final primera uno y dos del Real Decreto 1007/2023, de 5 de diciembre.

NO es obligatorio imprimir en papel la factura, siempre que se utilicen sistemas de facturación electrónica (ya sea estructurada o no estructurada).Por otro lado, cualquier impresión de una factura (ordinaria o simplificada), o imagen de la misma en soporte digital (factura electrónica no estructurada), debe llevar impreso o visible el QR y la demás información requerida. Por el contrario, si la factura es electrónica estructurada no se requiere la imagen del QR, pero sí su contenido (en forma de URL de la sede electrónica habilitada para este efecto).La remisión del registro de facturación (con todo el contenido al que se refieren los artículos 10 y 11 del RRSIF aprobado por RD 1007/2023) por parte de la empresa a la AEAT es una obligación adicional (en la modalidad VERI*FACTU), pero responde a otra finalidad y en nada contradice la obligación de incorporar el código «QR» o la url a las facturas emitidas.Normativa/Doctrina:

• Artículo 17 del reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

El servicio de cotejo de «QR» se va a poder realizar desde cualquier dispositivo que disponga de una cámara y tenga acceso al reconocimiento del QR para obtener la URL y conexión a la web.Para realizar el anterior proceso el uso de la APP de la AEAT es aconsejado, aunque no imprescindible. La APP de la AEAT es una garantía a la hora de asegurar que el «QR» incorporado a la factura y leído no sea irregular.

Con carácter general, los códigos «QR» en las facturas impresas (o visualizables) deberán figurar en al principio de la factura, antes de que empiece el contenido de esta. Por lo tanto, será siempre el primer código «QR» que aparecerá en la factura. Si se utiliza un formato de orientación vertical para organizar y disponer el contenido de la factura, el código «QR» se situará arriba de esta, próximo al margen superior, preferiblemente centrado o, si no, próximo al margen superior izquierdo. En el caso de utilizar un formato de orientación horizontal (apaisado) para la factura, el código «QR» se situará a la izquierda de esta, preferiblemente cercana al margen superior izquierdo (o, si no, centrada respecto a los márgenes superior e inferior de la factura). Se trata de homogeneizar su ubicación para que sea previsible su ubicación. No obstante, está previsto que, si existen obstáculos que hagan inconveniente esta ubicación, pueda adoptarse otra ubicación, siempre que sea claramente visible y se distinga de cualquier otro código o QR empleado. Si hay algún elemento preimpreso en el papel que se va a utilizar para imprimir la factura y que, por tanto, no es generado desde el SIF (como podría ser el logotipo de la empresa, suponiéndose que el resto de información la genera el SIF), la parte preimpresa, al no haber sido generada por el SIF podría mantenerse en su lugar, quedando el QR ubicado como primeelemento del “resto” de la factura que sí genera el SIF.El QR tributario solo debe aparecer una vez, al principio de la factura y antes del contenido de esta. Por lo tanto, si la factura ocupara más de una página, deberá figurar en la primera página y no en las siguientes.El planteamiento de ubicación al principio de la factura pretende alinearse con el espíritu del artículo 29.2.j de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por el artículo de la Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal, dado que así se logra dar máxima visibilidad al QR tributario, siendo un pilar fundamental del modelo. De esta forma se garantiza que sea visible, se normaliza y hace previsible su ubicación favoreciendo su uso y contribuyendo a la concienciación y colaboración ciudadana y a la transparencia en el cumplimiento fiscal de quien expide las facturas, lo que además contribuye a favorecer su buena imagen.Normativa/Doctrina:Orden Ministerial que desarrolla el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación (RRSIF), aprobado por el Real Decreto 1007/2023, de 5 de diciembre.

En cuanto al tamaño del código QR, en orden a una mayor normalización del mismo en todas las facturas, y a asegurar una legibilidad estándar, ha de estar comprendido dentro del rango exigido de dimensiones (que coincide con el adoptado en las especificaciones por las Haciendas Forales en el Proyecto TicketBAI), no pudiendo ser ni inferior ni superior.Ese tamaño debe situarse en la siguiente horquilla:• no puede ser menor de 30x30 mm• no puede ser mayor de 40x40 mm.Se considera que dicho rango es el más adecuado, para permitir albergar el contenido que debe incluirse en el código QR, y para facilitar su lectura por los dispositivos con capacidad para ello.