No es una API añadida al final

Adaptar software a medida exige tratar la facturación como un sistema completo, no añadir una llamada aislada a la AEAT. fuente oficial. El registro nace al expedir, se encadena, calcula su huella y no puede alterarse después. El QR de la factura y el estado de remisión dependen de ese mismo momento.

Un conector que lee facturas cerradas cada noche puede llegar tarde para definir la expedición conforme. Un servicio que solo envía XML tampoco resuelve series, borradores, correcciones, anulaciones, cadena, declaración responsable o recuperación. La arquitectura debe fijar un único dueño del cierre.

La empresa que desarrolla para uso propio puede ser productora y usuaria. El Reglamento no limita la obligación a proveedores comerciales. Asigna un responsable con autoridad sobre versión, componentes, despliegues y declaración. Sin esa persona, fiscalidad, desarrollo y operaciones pueden asumir que la responsabilidad pertenece a otro equipo.

Delimitar el SIF y su componente principal

La Orden define un componente principal como el que implementa o dirige las funciones necesarias para expedir facturas conforme. fuente oficial. El componente puede ser un módulo del ERP, un servicio compartido o una aplicación central. Debe controlar cuándo una factura deja de ser borrador.

Dibuja entradas: pedidos, TPV, suscripciones, partes, importaciones y edición manual. Dibuja salidas: PDF, factura estructurada, registro, contabilidad y cobro. Marca dónde se asigna número, se validan datos obligatorios, se genera QR y se persiste el registro. Si dos componentes pueden cerrar, elimina la ambigüedad.

Decide si varios terminales forman un SIF central o SIF independientes. La AEAT permite cadenas por cada SIF y obligado. No fuerces una cadena global si los centros expiden autónomamente; tampoco multipliques cadenas cuando solo existe un servicio de expedición.

Modelo de datos antes de XML

Separa el documento comercial del registro reglamentario. Conserva identidad, serie, número, fecha, destinatario, desglose, total, tipo de factura, referencias de rectificación y estado. El registro es una representación estructurada de datos exigidos, no una copia completa de todas las líneas del negocio.

Los borradores pueden editarse. La AEAT sitúa la expedición cuando se incorpora el QR y se genera el registro firmado o remitido. Después, los datos cubiertos no se cambian sobrescribiendo; se generan registros posteriores. fuente oficial

Usa estados explícitos: borrador, expedida, pendiente de remisión, aceptada, aceptada con incidencias si el protocolo lo contempla, rechazada, subsanada y anulada. No mezcles el estado fiscal del registro con pago o entrega al cliente.

Transacción de expedición

El cierre debe ser atómico en la medida posible. Reserva número, valida, persiste factura y registro, calcula huella y deja trabajo de remisión duradero. Si el proceso cae, la recuperación tiene que saber si existe una factura expedida. No repitas la asignación solo porque no llegó respuesta.

El encadenamiento usa información del registro anterior del mismo SIF y obligado. Protege la concurrencia. Dos nodos no deben calcular simultáneamente contra el mismo anterior. Una cola o bloqueo por cadena puede serializar el punto crítico sin bloquear toda la interfaz.

No borres registros fallidos. Conserva intentos y respuestas en una bitácora separada de los registros reglamentarios. La trazabilidad técnica ayuda a explicar por qué se reintentó y qué contenido exacto se envió.

Remisión VERI*FACTU

La Orden dispone mensajes XML y un control de flujo con tiempo de espera, número máximo de registros y respuestas. fuente oficial. El valor inicial de espera es de 60 segundos y la respuesta informa el valor aplicable al siguiente envío. No codifiques un cron fijo que ignore esa respuesta.

La autenticación, certificados y protocolos seguros forman parte de la capacidad de remisión. Diseña rotación sin parada, alertas de caducidad y custodia de claves. Separa credenciales de pruebas y producción. Un secreto copiado en el repositorio o en una imagen de contenedor no es aceptable.

La respuesta incluye un código seguro de verificación cuando se acepta al menos un registro y señala los erróneos. fuente oficial. Persiste respuesta por lote y por registro. La interfaz debe permitir localizar factura, payload, error, acción y resultado.

Reintentos e idempotencia

Una caída después de enviar y antes de guardar la respuesta crea incertidumbre. El sistema debe consultar o reintentar según el protocolo sin generar otra factura. Define claves de negocio y correlación. Prueba duplicados, timeout, respuesta parcial y reinicio durante la escritura.

No conviertas cualquier error en anulación. Un fallo de formato o comunicación no implica que la factura deje de existir. La subsanación del registro y la rectificación de una factura son procedimientos distintos. El motor debe guiar al usuario según el error.

Mantén una cola de incidencias con responsable y plazo interno. Una pantalla verde global oculta registros atascados. Alerta por edad, no solo por cantidad.

Modalidad no verificable como requisito de producto

Si el software también funcionará como no verificable, añade firma XAdES con certificado cualificado, registro de eventos, comprobaciones, conservación, exportación y precisión de hora. fuente oficial. No habilites un interruptor sin implementar el régimen completo.

La declaración debe indicar tipos de firma y si el sistema es exclusivamente VERIFACTU. Una base de código con ambas modalidades necesita pruebas y documentación separadas. El coste puede justificar ofrecer solo VERIFACTU si la operación admite remisión.

Si cada centro elige modalidad, separa configuración por SIF y obligado. Evita que un cambio administrativo altere cadenas ya activas sin proceso de renuncia.

Componentes externos y declaración responsable

La Orden exige declaración del sistema y de ampliaciones o componentes producidos por terceros. fuente oficial. Un motor contratado puede aportar su declaración, pero el productor del conjunto debe describir integración y versiones.

Inventaría librerías que calculan hash, generan QR, firman, remiten o asignan números. Registra licencias, versiones y soporte. Si una actualización cambia el formato, repite pruebas y revisa la declaración.

Comprar un motor externo conviene si reduce mantenimiento sin fragmentar la responsabilidad ni ocultar estados al ERP. criterio derivado. Rechaza cajas negras que solo devuelven “OK”. Necesitas correlación, errores, evidencias y salida al terminar el contrato.

Pruebas por capas

Recomendación editorial: delimita el sistema, congela la versión, genera y encadena, remite, resuelve respuestas, declara y prueba la recuperación. criterio derivado. Automatiza esquemas XML, campos obligatorios, hash y QR. Añade pruebas de propiedad: ninguna expedición válida carece de registro y ningún registro de alta apunta a una factura inexistente.

En integración, usa servicios de prueba de la AEAT y payloads válidos e inválidos. Comprueba códigos, certificados, lotes y tiempos. En sistema, simula concurrencia, caída de base, pérdida de red, reloj incorrecto y restauración.

La aceptación necesita casos fiscales reales y usuarios. Una prueba técnica no detecta que la interfaz permite expedir para el NIF equivocado. En multiobligado, cambia de contexto y verifica cadenas separadas.

Despliegue y observabilidad

Despliega por grupos controlados. Mide facturas expedidas, registros creados, pendientes, aceptados, rechazados y edad máxima. Los totales deben conciliar. No uses datos personales completos en logs; conserva solo lo necesario y protege accesos.

Versiona configuración, esquemas y endpoints. Registra quién cambió series, modalidad o certificado. Las alertas deben llegar a una persona capaz de actuar, con procedimiento y suplencia.

Una copia de seguridad se prueba restaurándola. Verifica que no reaparecen colas antiguas como nuevas y que la identidad de instalación se gestiona. En no verificable, la restauración genera obligaciones de evento que el sistema debe contemplar.

Seguridad y privacidad

Los registros contienen NIF, importes y datos de factura. Minimiza exposición en colas, soporte y entornos de prueba. Usa datos ficticios en desarrollo. Cifra tránsito y almacenamiento, separa roles y registra accesos.

Los certificados cualificados y claves privadas requieren inventario y rotación. Si un proveedor opera el servicio, delimita encargado, subencargados, ubicación y respuesta a incidentes. Fiscalidad no reemplaza RGPD ni seguridad.

No permitas que soporte descargue bases completas para analizar un rechazo. Prepara herramientas de diagnóstico con payload mínimo, identificadores y trazas protegidas.

Convivencia con factura electrónica B2B

VERI*FACTU genera registros tributarios. La factura electrónica B2B regula expedición, transmisión y recepción estructurada entre empresarios, plataformas y estados. El RD 238/2026 ya existe, pero su aplicación efectiva se cuenta desde la entrada en vigor de una orden de desarrollo de la solución pública. fuente oficial

Diseña un modelo común de factura, pero separa adaptadores. El registro VERI*FACTU y la factura estructurada B2B no son el mismo mensaje. Evita acoplar la expedición a un único formato futuro cuya orden técnica todavía debe vigilarse.

La inversión útil es una identidad estable de factura, estados separados y arquitectura de eventos. Eso permite conectar remisión tributaria, entrega B2B y contabilidad sin confundir aceptación técnica con pago.

Límites de la aceptación AEAT

Una respuesta aceptada por la AEAT no valida el criterio fiscal ni todos los datos comerciales de la factura. criterio derivado. Prueba formato y recepción. El emisor sigue respondiendo por realidad, descripción, tipo impositivo y demás menciones.

Tampoco sustituye entrega al cliente. Conserva evidencia del canal y documento. No marques pagada una factura porque el registro se aceptó.

El ámbito estatal excluye supuestos como SII y territorios forales según sus reglas. No actives el motor para todos los NIF sin clasificación.

Expediente de producto

Mantén arquitectura, catálogo de SIF, declaraciones, versiones, matrices de trazabilidad, esquemas, casos, resultados y decisiones. Añade fuentes oficiales consultadas y fecha. El expediente permite demostrar qué se implementó y repetir la revisión cuando cambia una especificación.

Vincula cada despliegue a un hash y a la declaración. Conserva notas sobre migración de cadenas e identidad de instalación. No guardes solo el último estado.

El calendario vigente exige adaptación antes de 2027 según colectivo. Usa el tiempo para observar producción, no solo para terminar código el día anterior.

Contrato entre el ERP y el motor fiscal

Define un esquema versionado para la orden de expedición. Incluye identificador interno, obligado, instalación, serie, número o solicitud de numeración, fechas, tipo, destinatario, desglose y referencias. El motor devuelve identidad de factura, registro, QR, estado y correlación. Ninguna parte debería reconstruir esos datos a partir del PDF.

Aclara quién valida cada campo. El ERP conoce negocio; el motor conoce formato reglamentario. Si ambos corrigen silenciosamente, el documento entregado puede diferir del registro. Devuelve errores antes de expedir y bloquea valores ambiguos.

Los mensajes deben ser idempotentes. Repetir la misma solicitud tras timeout devuelve el resultado existente o un conflicto identificable, nunca un número nuevo. Versiona contratos de error para que la interfaz no transforme un rechazo en texto genérico.

Migración de registros y cadenas

No se recrea el historial en el nuevo motor como si se expidiera hoy. Conserva sistema anterior, declaraciones, registros y facturas. Define último documento por serie y fecha de corte. El nuevo SIF empieza su cadena según la arquitectura y especificaciones aplicables.

Si se cambia solo un componente conservando el SIF, el productor debe evaluar continuidad, versión e identidad de instalación. No decidas con una regla general sin conocer implementación. Documenta hash anterior, colas y estado antes del despliegue.

Importa datos maestros y saldos operativos por separado. Una factura histórica puede aparecer para consulta, marcada como migrada, sin habilitar funciones de alteración o nueva remisión.

Rendimiento y picos de facturación

La serialización por cadena no obliga a procesar toda la empresa en un hilo. Particiona por SIF y obligado, prepara datos en paralelo y limita el tramo crítico. Mide latencia en cierre, tamaño de lote y acumulación de cola.

Prueba cierres de día, campañas y reinicios. El control de flujo de la AEAT puede cambiar el tiempo entre envíos; dimensiona almacenamiento y alertas para pendientes. No pierdas ventas por una interfaz que espera sin necesidad la respuesta antes de entregar, si el comportamiento conforme permite gestionar cola.

Establece límites de presión. Si la cola supera capacidad o edad, el sistema debe avisar y aplicar el plan, no seguir hasta agotar disco. Protege registros con transacciones y copias consistentes.

Revisión de código orientada a riesgos

Busca rutas que actualizan facturas expedidas, borran registros, recalculan hash, reinician numeradores o cambian obligado. Revisa reintentos sin clave, logs con datos completos y certificados embebidos. Analiza restauración y tareas administrativas.

Prueba permisos: un usuario de soporte no debe alterar datos; un administrador no debería borrar evidencia. Los cambios de configuración crítica generan auditoría y, donde aplique, eventos reglamentarios.

Revisa dependencias que procesan XML, firma y QR contra versiones oficiales. Congela y escanea. Una actualización automática de librería no debe cambiar serialización y huella sin repetir vectores.

Operación después del lanzamiento

El equipo fiscal revisa conciliación y casos; tecnología vigila disponibilidad y colas; soporte resuelve interacción; seguridad custodia credenciales. Define rotación y suplencia. Un sistema a medida fracasa cuando el único desarrollador que conoce la remisión se marcha.

Programa pruebas de recuperación y certificado. Revisa especificaciones AEAT y cambios normativos con propietario y fecha. Actualiza declaración responsable cuando proceda. Mantén entorno de pruebas representativo sin datos reales.

Tras cada incidente, conserva cronología, registros afectados, decisión y prueba. No corrijas directamente en base. Las herramientas administrativas también forman parte del producto y deben respetar inalterabilidad.

Criterio de aceptación final

Bloquea si existe una factura expedida sin registro, un registro sin factura, duplicación por reintento, imposibilidad de saber el estado, alteración del original o falta de declaración. Bloquea también si una operación material del negocio no se puede corregir conforme.

Acepta cuando versiones y componentes están documentados, pruebas técnicas y fiscales pasan, recuperación funciona, seguridad está revisada y operación tiene responsables. Mantén defectos menores con plazo y evidencia.

No uses porcentaje global. Un 99 % de pruebas superadas puede ocultar que el 1 % es la restauración que duplica un día completo.

Documentación para soporte de primer nivel

El manual debe enseñar a distinguir borrador, factura expedida, registro pendiente, rechazo técnico, rectificación y anulación. Incluye capturas solo para orientar; los pasos deben referirse a estados y datos. Un cambio visual no debería dejar el procedimiento inútil.

Prepara diagnósticos que muestren identificador, factura, intento, respuesta y versión sin revelar datos completos. El soporte de primer nivel puede resolver certificados, conexión o validaciones conocidas. Los casos fiscales pasan a una persona competente; los defectos de producto, a desarrollo con evidencia reproducible.

Mantén una lista de errores conocidos con acción segura. No instruyas a repetir expedición ni a modificar base. Cada solución temporal tiene fecha de retirada y prueba posterior.

Auditoría periódica del sistema en producción

Muestrea facturas y compara documento, registro, respuesta y asiento. Concilia todos los estados agregados. Revisa usuarios con permisos críticos, certificados próximos a caducar, colas antiguas y versiones de componentes. Ejecuta una exportación y una restauración controlada.

Comprueba que la declaración sigue accesible y coincide con producción. Revisa altas de nuevas sociedades, centros y canales. Una integración comercial añadida por otro proyecto puede haber entrado en el circuito sin evaluación.

Documenta hallazgos y correcciones. Una revisión trimestral al inicio puede pasar a semestral cuando el sistema sea estable, sin abandonar alertas diarias. Los cambios normativos activan una revisión extraordinaria.

Desmantelar el sistema sin perder evidencia

Antes de retirar, bloquea nuevas expediciones, resuelve pendientes, exporta documentos, registros, respuestas, configuración y declaraciones. Conserva el software o un medio legible durante el plazo necesario. Revoca credenciales y certificados cuando ya no intervengan.

El nuevo sistema recibe datos maestros y referencias históricas, no reexpide. Concilia último y primer día y registra la decisión sobre series. Si un componente externo conserva información, exige devolución o acceso según contrato.

La retirada forma parte del diseño desde el principio. Un motor que cumple mientras funciona pero encierra evidencia al terminar deja a la empresa con un problema fiscal y operativo.

Haz una sesión con desarrollo, fiscalidad y operaciones. Expide una factura y corta el proceso justo después de persistir el registro, después de enviar y antes de guardar respuesta. Recupera sin duplicar número ni alta. Repite con rechazo y rectificación.

La guía general de VERI*FACTU ayuda a fijar ámbito y calendario. El equipo fiscal-contable de TaxFactory puede revisar casos, estados y responsabilidades. Una integración está lista cuando el sistema sabe qué ocurrió incluso en el peor momento, no cuando devuelve el primer 200.

Preguntas frecuentes

¿Un desarrollo interno necesita declaración responsable?

Sí. El Reglamento incluye a productores de SIF y la declaración identifica sistema, versión, componentes y productor. Ser usuario y productor a la vez no elimina la obligación documental.

¿Puede un servicio externo generar los registros?

Puede formar parte de la arquitectura, pero deben delimitarse componente principal, responsabilidades, versiones y declaraciones. La empresa no debe perder el control del vínculo entre factura y registro.

¿Se envía el PDF de la factura a la AEAT?

VERI*FACTU remite registros estructurados de alta o anulación en XML conforme a la Orden, no el PDF como mecanismo ordinario de remisión.

¿Qué ocurre cuando la AEAT rechaza un registro?

La respuesta identifica registros erróneos y el tipo de error. El sistema debe conservar el vínculo, mostrar el estado y aplicar la subsanación o reenvío procedente sin duplicar la expedición.

¿Una API conforme convierte todo el ERP en conforme?

No por sí sola. También deben cumplirse expedición, inalterabilidad, cadena, QR, componentes, configuración, errores y declaración del conjunto desplegado.