Los errores que más comprometen una implantación VeriFactu
Una implantación estable no depende de instalar un plugin y activar un interruptor. Depende de definir correctamente quién actúa como SIF, cuándo se expide la factura, cómo se evitan duplicidades y qué ocurre con devoluciones, rectificativas, impuestos, registros y reintentos.
WooCommerce gestiona pedidos, pagos, estados, devoluciones y comunicaciones con servicios externos. VeriFactu añade otra capa: el sistema debe generar registros de facturación coherentes, trazables e inalterables. La mayoría de incidencias aparecen cuando ambas operativas se conectan sin definir responsabilidades, eventos y controles.
Esta guía no sustituye la revisión fiscal del negocio. Se centra en los errores técnicos y operativos que conviene detectar antes de implantar una solución VeriFactu en WooCommerce.
Tres conceptos que deben estar claros
WooCommerce no es necesariamente el SIF
Puede ser el origen del pedido y de los datos comerciales, mientras otro componente genera y gestiona los registros de facturación.
VERI*FACTU y NO VERI*FACTU tienen diferencias
La remisión, la firma del registro y el registro de eventos no funcionan igual en ambas modalidades.
La factura visible no es todo el sistema
PDF, QR, registro, huella, estados y evidencias técnicas son piezas distintas que deben permanecer coherentes.
Diez errores que conviene detectar antes de producción
No se identifica qué componente actúa realmente como SIF.
Se factura antes de confirmar el cobro o demasiado tarde.
La representación visual no sustituye al registro técnico.
Se mezclan canales, tipos documentales o históricos.
Documento, pedido y registro dejan de coincidir.
Devolver dinero no crea por sí solo una rectificativa.
Webhooks, cron y callbacks vuelven a procesar el mismo evento.
NIF, IVA, exenciones o país se validan demasiado tarde.
La primera factura real se convierte en la prueba de integración.
Se cargan certificados sin revisar si la arquitectura los requiere.
Elegir una solución sin verificar quién actúa como SIF
Un plugin puede limitarse a añadir campos al checkout, generar un PDF o conectar WooCommerce con un ERP. Ninguna de esas funciones demuestra por sí sola que el plugin sea el componente que produce los registros de facturación.
Antes de contratar hay que identificar quién es el productor del SIF, qué versión se utiliza, qué modalidad admite, dónde está su declaración responsable y qué parte del mantenimiento normativo asume el proveedor.
- Solicitar la declaración responsable del producto y de la versión concreta.
- Distinguir entre helper, conector, ERP, SaaS y plugin que actúa como SIF.
- Documentar qué responsabilidades corresponden al productor, a Webyseo y al titular de la tienda.
- Comprobar que la solución es compatible con la versión de WooCommerce, PHP y HPOS utilizada.
La AEAT no publica una lista de plugins WordPress “homologados”. La conformidad se acredita mediante la declaración responsable del productor para cada producto y versión.
Expedir la factura en el estado de pedido equivocado
WooCommerce puede pasar por estados como pending payment, on hold, processing o completed. El problema aparece cuando la factura se genera por un cambio de estado que no representa realmente la expedición en ese negocio.
Los pagos asíncronos, autorizaciones pendientes, transferencias, productos virtuales y callbacks tardíos pueden hacer que una regla aparentemente simple emita facturas antes de confirmar el cobro o genere documentos demasiado tarde.
- Definir por escrito el evento de expedición de cada tipo de pedido.
- Probar pasarelas con confirmación inmediata y diferida.
- No utilizar un estado universal sin revisar transferencias, autorizaciones, suscripciones y productos virtuales.
- Registrar en las notas del pedido cuándo y por qué se generó la factura.
Confundir el PDF o el código QR con el cumplimiento
Un PDF bien diseñado puede contener numeración, impuestos y QR, pero seguir sin estar respaldado por un registro de facturación válido. Del mismo modo, un QR no prueba por sí solo que exista una arquitectura SIF correcta.
La factura visible para el cliente, el registro técnico, la huella, el encadenamiento y la modalidad de remisión o conservación son elementos relacionados, pero no equivalentes.
- Identificar qué componente genera el registro de facturación.
- Comprobar que el PDF se genera a partir de los mismos datos que el registro.
- Validar el QR mediante escaneo y contraste de NIF, número, fecha e importe.
- No regenerar la factura con datos diferentes después de su expedición.
Consulta también la guía sobre cómo funciona el código QR de VeriFactu en WooCommerce.
Configurar series y numeración sin revisar el histórico
El error no consiste únicamente en dejar un salto. También puede aparecer al mezclar en una misma serie WooCommerce, facturación manual, ERP, puntos de venta, facturas simplificadas o rectificativas sin un diseño previo.
Una migración mal planteada puede reutilizar números, romper la continuidad o provocar que dos sistemas intenten controlar la misma serie.
- Inventariar todas las series y canales que ya expiden facturas.
- Definir qué sistema es el maestro de numeración.
- Separar las series cuando corresponda por tipo documental, establecimiento o canal.
- Documentar el punto de corte entre el sistema anterior y el nuevo.
- Impedir que WordPress y el ERP asignen simultáneamente números definitivos.
Modificar un pedido después de expedir la factura
Después de la expedición, cambiar cantidades, impuestos, dirección fiscal o descuentos directamente en el pedido puede dejar tres realidades distintas: el pedido actual, el PDF entregado y el registro producido por el SIF.
La corrección debe seguir un flujo fiscal definido. Según el caso puede requerir una factura rectificativa, un registro de anulación o una nueva factura, pero no una simple edición silenciosa del pedido.
- Bloquear o advertir la edición de pedidos que ya tengan factura expedida.
- Conservar una copia o evidencia de los datos utilizados en la emisión.
- Canalizar las correcciones por el flujo de rectificativas o anulación previsto.
- Registrar usuario, fecha, motivo y documentos relacionados.
Confundir el reembolso de WooCommerce con una rectificación fiscal
WooCommerce permite reembolsos automáticos o manuales, totales o parciales. Esa operación modifica el pedido y, si la pasarela es compatible, devuelve el dinero. Sin embargo, el reembolso no crea necesariamente por sí solo la factura rectificativa exigida por el flujo fiscal.
- Relacionar cada reembolso con el documento fiscal que corresponda.
- Probar devoluciones parciales y totales por separado.
- Verificar que la rectificativa enlaza con la factura original.
- Comprobar importes, IVA, serie rectificativa y nuevo saldo del pedido.
Amplía este punto en facturas rectificativas y VeriFactu en WooCommerce.
No controlar duplicidades causadas por webhooks, cron o reintentos
WooCommerce y las pasarelas pueden notificar el mismo evento más de una vez. También puede repetirse un proceso después de un timeout, una respuesta tardía, un reintento de cron o una entrega duplicada de webhook.
Si la integración no es idempotente, el mismo pedido puede intentar generar dos facturas o dos remisiones.
- Utilizar una clave única por pedido, documento y operación.
- Bloquear temporalmente el proceso mientras una emisión está en curso.
- Distinguir entre “solicitud enviada”, “respuesta recibida” y “estado confirmado”.
- Reintentar únicamente operaciones recuperables y conservar el detalle del error.
- Revisar los logs de entrega de webhooks y las acciones programadas.
Emitir con impuestos o datos fiscales incorrectos
Un checkout puede permitir pedidos sin NIF, con país incoherente, exenciones mal aplicadas o reglas de IVA que no coinciden con la operativa real. Cuando el error se detecta después de expedir, la corrección deja de ser un simple cambio de pedido.
- Definir cuándo NIF, razón social y domicilio son obligatorios.
- Validar formatos sin presentar esa validación como asesoramiento fiscal.
- Probar ventas nacionales, B2B, intracomunitarias, exentas y con recargo cuando apliquen.
- Comprobar redondeos, cupones, portes e impuestos a nivel de línea.
- Validar los criterios tributarios con la asesoría del cliente.
Activar VeriFactu directamente en producción
Las pruebas en una tienda real pueden enviar correos, afectar stock, registrar pedidos en analítica o activar integraciones externas. Además, WooCommerce no diferencia por defecto todos los pedidos de prueba de los pedidos reales para el resto de extensiones.
La compatibilidad con HPOS también debe comprobarse: las extensiones que leen o escriben directamente en wp_posts o postmeta pueden trabajar con datos desactualizados cuando los pedidos se almacenan en tablas específicas.
- Probar exclusivamente en un entorno de staging que reproduzca producción.
- Activar modos sandbox de las pasarelas y desactivar comunicaciones no necesarias.
- Comprobar compatibilidad con HPOS, checkout clásico o bloques y plugins de pago.
- Preparar copia, procedimiento de reversión y ventana de activación.
- Monitorizar las primeras operaciones después del despliegue.
Gestionar certificados y credenciales sin revisar la arquitectura
No todas las soluciones requieren que el certificado del cliente se cargue directamente en WordPress. Algunas autentican la remisión desde una plataforma externa y otras necesitan credenciales o certificados en el propio entorno.
Además, los registros VERI*FACTU no están obligados a firmarse electrónicamente, mientras que los sistemas NO VERI*FACTU sí tienen requisitos adicionales de firma y registro de eventos.
- Documentar qué credencial utiliza cada comunicación y dónde se almacena.
- No subir certificados a WordPress si la arquitectura no lo exige.
- Restringir permisos, cifrar secretos y evitar contraseñas en código o repositorios.
- Controlar caducidad, renovación y titularidad del certificado cuando se utilice.
- Eliminar accesos temporales después de la implantación.
Matriz mínima de pruebas antes de activar
La configuración no debe considerarse válida porque una factura normal funcione. Hay que reproducir los escenarios que pueden alterar importes, estados o documentos.
| Escenario | Qué debe comprobarse | Resultado esperado |
|---|---|---|
| Pedido pagado | Evento de emisión, serie, impuestos, QR y relación con el pedido. | Una única factura |
| Pago fallido | Que un intento de cobro fallido no produzca una factura definitiva. | Sin expedición |
| Pago asíncrono | Respuesta tardía, webhook y transición correcta de estado. | Emisión al confirmar |
| Webhook duplicado | Dos notificaciones con el mismo identificador. | Sin duplicado |
| Reembolso parcial | Importes, IVA, rectificativa y vínculo con la factura original. | Saldo coherente |
| Reembolso total | Estado del pedido, devolución del pago y documento fiscal asociado. | Flujo completo |
| Cliente empresa | NIF, razón social, domicilio y tratamiento fiscal configurado. | Datos consistentes |
| Error de comunicación | Log, cola, reintento, bloqueo y recuperación. | Recuperable |
| HPOS / actualización | Lectura y escritura de pedidos después de actualizar extensiones. | Compatibilidad |
Checklist operativo final
- Productor, versión y declaración responsable documentados.
- Modalidad VERI*FACTU o NO VERI*FACTU identificada.
- Evento de expedición definido para cada medio de pago.
- Series, numeración e histórico revisados.
- Datos fiscales e impuestos validados con la asesoría.
- Rectificativas y reembolsos parciales probados.
- Control de idempotencia y duplicados verificado.
- Logs y cola de reintentos accesibles.
- Compatibilidad con HPOS y extensiones confirmada.
- Staging, copia y plan de reversión preparados.
- Credenciales y certificados almacenados de forma segura.
- Primeras facturas de producción monitorizadas.
Analizo la operativa de tu WooCommerce, identifico dependencias, preparo las pruebas y te indico qué implantación tiene sentido antes de modificar producción.
Dudas sobre errores al implantar VeriFactu
¿Debo generar la factura cuando el pedido pasa a “processing”?
No existe una respuesta universal. Depende de cuándo se considera expedida la factura en la operativa del negocio, del medio de pago y de si la confirmación es inmediata o diferida. La regla debe definirse y probarse por escenario.
¿Necesito obligatoriamente un plugin de facturas PDF?
No necesariamente. Lo imprescindible es que exista una solución que expida la factura y produzca el registro conforme al RRSIF. El PDF puede ser la representación entregada al cliente, pero no es por sí mismo el SIF.
¿Un reembolso automático genera siempre la rectificativa?
No. WooCommerce puede devolver el dinero y actualizar el pedido, pero la generación de la factura rectificativa depende de la solución de facturación implantada y de su configuración.
¿Todos los sistemas VeriFactu necesitan certificado digital en WordPress?
No. Algunas arquitecturas gestionan la autenticación desde una plataforma externa. Antes de cargar certificados en WordPress hay que confirmar cómo autentica y remite realmente la solución elegida.
¿Por qué es importante probar webhooks duplicados?
Porque las pasarelas y servicios externos pueden reenviar notificaciones. La integración debe reconocer que el evento ya fue procesado y evitar una segunda expedición o remisión.
¿Qué ocurre si el plugin no es compatible con HPOS?
Puede leer o escribir datos de pedido incorrectos o desactualizados. La compatibilidad debe verificarse antes de activar HPOS o antes de depender del plugin para la facturación.
Guías relacionadas
Servicio técnico, metodología, pruebas y alcance de la implantación.
Ver servicio → Plugins VeriFactu para WooCommerceComparativa de helpers, conectores, SaaS y soluciones especializadas.
Ver comparativa → Facturas rectificativasDevoluciones, rectificación fiscal, series y trazabilidad del documento original.
Ver guía → Código QR VeriFactuQué contiene, cómo responde la AEAT y qué validar en el PDF.
Ver guía → VeriFactu en WordPressArquitectura técnica, flujo de registros y checklist para WooCommerce.
Ver arquitectura → Qué es VeriFactuConceptos generales, modalidades y plazos oficiales de adaptación.
Ver guía general →Fuentes oficiales y técnicas
- AEAT: modalidades VERI*FACTU y NO VERI*FACTU.
- AEAT: declaración responsable del productor del SIF.
- AEAT: registro de eventos y modalidades.
- WooCommerce: estados de pedido.
- WooCommerce: reembolsos automáticos y manuales.
- WooCommerce: webhooks y logs de entrega.
- WooCommerce: pruebas de pedidos en staging.
- WooCommerce: High-Performance Order Storage.
Alcance: este artículo describe controles técnicos y operativos para WooCommerce. La clasificación fiscal de operaciones, los tipos impositivos, las obligaciones de facturación y la causa concreta de una rectificación deben validarse con el asesor tributario del negocio.
Deja tu comentario