El documento y el registro no tienen la misma función.
La factura documenta una operación y se entrega a su destinatario. En modalidad VERI*FACTU, el sistema genera y remite a la Agencia Tributaria un registro estructurado de facturación. Esa remisión no equivale al envío del documento al cliente.
Por eso, preguntar si un sistema cumple con VERI*FACTU no resuelve por sí solo cómo entregarás las facturas o qué formatos utiliza tu cliente. Son decisiones relacionadas, pero distintas.
Funcionamiento del sistema y remisión de registros.
Emisión, transmisión y recepción de la factura electrónica.
Qué debes comprobar
Modalidad, versión y documentación del sistema.
Formato y canal admitidos por el destinatario y el marco aplicable.
Qué evitar
Confundir el envío del registro con la entrega al cliente.
Dar por resuelta toda obligación por disponer de un PDF.
Tres preguntas para tu próxima demo.
¿Cómo genera y remite el sistema los registros? ¿Cómo obtengo y entrego la factura a mi cliente? ¿Qué sucede si mi cliente necesita un formato o canal concreto? Pide que cada respuesta identifique el paso del proceso y sus condiciones.
Esta separación también resulta útil si trabajas con varias aplicaciones. El origen del pedido, el sistema que emite y el canal de entrega pueden ser distintos; hay que acordar qué información intercambia cada uno.
Evalúa tu actividad, no una etiqueta.
Prepara ejemplos de operaciones y de los destinatarios con los que trabajas. Si un requisito afecta a un grupo de clientes, identifica cuál es y cómo lo resuelves hoy.
Contrasta el ámbito normativo de tu negocio con tu asesoría y revisa la documentación correspondiente. No deduzcas calendarios u obligaciones distintas a partir de una afirmación general sobre VERI*FACTU.
Sigue una venta y verás dónde se separan los procesos.
Imagina un servicio profesional de 1.000 euros antes de impuestos. Primero se define la operación y se prepara su factura. Después hay que documentarla, entregarla por el canal que corresponda y seguir el cobro. A la vez, el sistema de facturación debe resolver sus obligaciones de registro. El ejemplo sirve para organizar tareas; no determina el tratamiento fiscal de esa operación.
Una misma venta puede aparecer en varias herramientas: el CRM conserva la relación comercial, el programa emite la factura y el banco refleja un movimiento de dinero. No todos esos datos acreditan lo mismo. Tener un pedido confirmado no demuestra por sí solo que exista una factura emitida, y remitir un registro no demuestra que el cliente haya pagado.
Diferencia cumplimiento, compatibilidad y experiencia de uso.
El cumplimiento responde a las obligaciones aplicables al sistema y a la operación. La compatibilidad responde a si puedes intercambiar la información con otra aplicación o destinatario. La experiencia de uso describe cuánto trabajo te exige completar el recorrido. Un producto debe evaluarse desde las tres perspectivas.
Una captura de pantalla no acredita la compatibilidad con el canal de un cliente. Una declaración responsable tampoco describe todas las integraciones comerciales del producto. Solicita la evidencia adecuada a cada pregunta: documentación de cumplimiento, especificaciones de intercambio y demostración del funcionamiento.
Preguntas para comparar dos soluciones
Necesidad
Pregunta concreta
Qué pedir como respuesta
Registro
¿Qué modalidad utiliza esta versión?
Identificación del sistema y documentación
Entrega
¿Cómo recibe la factura mi destinatario?
Formato, canal y condiciones admitidos
Seguimiento
¿Qué significa cada estado?
Ejemplo de emisión, entrega, remisión y cobro
Integración
¿Quién decide que una operación se emita?
Regla de negocio y tratamiento de duplicados
Incidencias
¿Qué hago si no obtengo confirmación?
Procedimiento y responsable de soporte
Qué cambia si intervienen varias aplicaciones.
Cuando una tienda online o un sistema de gestión envía información al programa de facturación, hay que acordar qué datos son definitivos y cuáles pueden variar. Un cambio de dirección posterior a un pedido, por ejemplo, debe tratarse según el momento del proceso y la información que ya se haya emitido.
Para evitar duplicados, la integración necesita una relación identificable entre la operación de origen y su resultado. No conviene usar únicamente el nombre del cliente o el importe para decidir si dos registros son el mismo. Pide al proveedor que explique cómo resuelve reintentos, cambios y respuestas pendientes.
No mezcles los calendarios al planificar.
Un plazo de adaptación del sistema de facturación no debe copiarse automáticamente a un proyecto de factura electrónica. Identifica la norma, los sujetos afectados y el hecho que determina el inicio de cada obligación. Si una fecha depende de una disposición posterior, hay que revisar esa disposición antes de convertirla en una fecha cerrada.
En marzo de 2026 se publicó el Real Decreto 238/2026 sobre facturación electrónica obligatoria entre empresarios y profesionales. Su existencia refuerza la necesidad de revisar ese marco por separado. Esta guía no fija un calendario de aplicación de factura electrónica B2B: consulta el texto consolidado y sus desarrollos vigentes para tu caso.
Redacta tus requisitos en frases comprobables: «necesito entregar a este tipo de destinatario», «debo recuperar estas facturas» o «quiero conocer el resultado de esta remisión». Vincula cada requisito a una función, una condición contractual o una integración concreta.
Si una necesidad queda pendiente, anota quién debe confirmarla y con qué documentación. La comparación será más precisa que marcar una única casilla llamada «factura electrónica» que intente representar todo el proceso. VerifacturDocs se presenta como software de facturación que cumple con VERI*FACTU; las demás necesidades deben concretarse en el alcance comercial.