Guía
Integrar WooCommerce con Holded: dónde se rompe.
Sí, WooCommerce se integra con Holded: cada pedido genera su factura y al cliente le llega sola, sin que nadie la emita a mano. La instalación es la parte fácil y está contada en muchos sitios. Lo que casi nadie cuenta es que la integración no se rompe el día que se monta, sino meses después, y siempre por los mismos cuatro sitios: el momento en que se emite la factura, los pedidos sin NIF, los reembolsos parciales y la conciliación bancaria. Y debajo de los cuatro hay una decisión que se suele tomar sin querer: si la tienda y el ERP emiten cada uno su factura, alguien acaba comparándolas a mano para siempre.
Llevo esta integración funcionando en mis propias tiendas. Lo que sigue no es la guía de instalación: es la lista de lo que se rompe cuando ya lleva tiempo puesta y nadie está mirando.
El punto de partida
¿Qué sincroniza de verdad una integración de WooCommerce con Holded?
Menos de lo que la gente espera. Una integración de WooCommerce con Holded mueve el pedido hacia la factura y el contacto hacia la ficha de cliente. Lo demás —el cobro, la conciliación y el cierre contable— sigue siendo trabajo aparte, y ahí es donde empiezan los problemas de quien creía que había automatizado «la contabilidad».
| Dato | ¿Viaja solo? | Lo que hay que vigilar |
|---|---|---|
| Pedido → factura de venta | Sí | El estado del pedido que la dispara, y que la serie de numeración no se parta |
| Cliente → contacto | Sí | Duplicados por email distinto y NIF ausente |
| Reembolso → abono | A medias | Los parciales suelen quedarse sin abono |
| Cobro → pago conciliado | No | Es un proceso aparte, contra el banco y la pasarela |
| Cierre contable | No | Holded lleva la contabilidad —cuentas, asientos, libro mayor y balance—, pero el cierre no lo hace la integración: es trabajo aparte dentro del ERP |
Lo que no cuentan los tutoriales
¿Dónde se rompe una integración de WooCommerce con Holded?
1 · En el estado del pedido que emite la factura
Hay que decidir si la factura sale cuando el pedido pasa a «procesando» o cuando pasa a «completado», y esa decisión parece menor hasta que deja de serlo. Si sale en «procesando», facturas cosas que todavía pueden cancelarse y acabas emitiendo abonos de pedidos que nunca salieron del almacén. Si sale en «completado», dependes de que alguien marque los pedidos, y el día que ese alguien se va de vacaciones dejas de facturar sin que salte ningún aviso. El fallo no avisa: simplemente el número de facturas del mes no cuadra con el de pedidos, y eso solo se ve si alguien lo mira.
2 · En los pedidos sin NIF
Una tienda B2C cobra sin pedir el NIF, porque pedirlo en el checkout cuesta ventas. Y hace bien: el Reglamento de facturación admite la factura simplificada sin NIF del destinatario hasta 400 € con IVA, y hasta 3.000 € con IVA en ventas al por menor. El problema no es que falte el NIF, es lo que pasa después: cuando el cliente resulta ser empresario o profesional y lo pide, hay que poder incluirlo —con su domicilio y la cuota repercutida por separado—, y eso obliga a rehacer el documento. Lo razonable es no pelearse con el checkout: dejar que el pedido entre sin NIF y tener una vía para completarlo cuando el cliente lo reclama, en vez de convertir un campo obligatorio en una criba de compradores.
3 · En los reembolsos parciales
Un reembolso total se refleja casi siempre. Un reembolso parcial —el cliente devuelve dos de cinco artículos— es el caso que más veces se queda a medias: el dinero sale de la pasarela y en el ERP la factura sigue completa. Es el error más caro de los cuatro, porque no da la cara en el momento; da la cara al trimestre siguiente, cuando el IVA declarado no coincide con el cobrado.
4 · En la conciliación, que es un proceso distinto
Que la factura exista en Holded no significa que el cobro esté casado con su movimiento bancario. Son dos cosas distintas y la integración solo hace la primera. Esto tiene una consecuencia práctica que confunde a mucha gente y que conviene saber antes de tomar decisiones con esos datos.
El estado «pendiente» de una compra en Holded no significa que se deba dinero. Significa que ese documento no está conciliado con un movimiento bancario. Son cosas distintas, y en la práctica se separan mucho: es perfectamente normal encontrar documentos marcados como pendientes que llevan años pagados. Si alguien lee esa columna como «deuda viva» —y es la lectura natural— se lleva una cifra que no existe. Antes de usar ese número para cualquier decisión, hay que contrastarlo con el banco.
Límites reales
¿Qué no se puede automatizar con la API de Holded?
La respuesta honesta empieza por una pregunta: ¿contra qué estás integrando? Holded convive hoy con dos superficies de API —la clásica de facturación, bajo /api/invoicing/v1/, y una segunda generación con sus propios recursos bajo /api/v2/, con rutas para compras y para pagos—. Una integración escrita contra la primera no hereda lo que sepa hacer la segunda, y un conector que lleva tres años funcionando casi nunca se ha reescrito.
Por eso desconfía de cualquier lista de «esto no se puede» sin fecha y sin versión, la mía incluida. Lo que no caduca son las tres preguntas que de verdad deciden el proyecto.
| La pregunta | Por qué decide el proyecto |
|---|---|
| ¿Contra qué versión de la API integras? | El alcance cambia entre ellas. Lo que el conector viejo no hacía puede existir hoy en otra ruta, y lo que hoy funciona puede dejar de estar documentado mañana. |
| ¿El documento que creas genera asiento, o solo queda registrado? | No es lo mismo dejar constancia de una compra que generar el gasto y el IVA soportado. Es la diferencia entre una integración que te ahorra trabajo y una que se lo pasa a tu asesoría. |
| ¿Quién concilia, y contra qué? | El cobro de la pasarela, el apunte del banco y el pago del ERP son tres cosas distintas. La integración puede traer el dato; casarlos es un proceso aparte, y es donde se va el tiempo. |
La consecuencia práctica es que el circuito de ventas y el de compras son dos proyectos, no uno con dos mitades. Quien te venda «automatizamos tu contabilidad» sin distinguirlos, o no ha llegado al segundo o no te lo va a contar.
La decisión de fondo
¿Quién debe emitir la factura, la tienda o el ERP?
Debajo de los cuatro puntos anteriores hay una decisión de arquitectura que casi nadie plantea, y que se toma sin querer: si la tienda emite su propia factura y el ERP emite la suya, tienes dos facturas del mismo pedido. Dos documentos, dos numeraciones y dos verdades. Y entonces aparece una tarea que no acaba nunca: comparar lo que se envió desde la web con lo que hay en el ERP para comprobar que dicen lo mismo. Cada pedido nuevo la vuelve a abrir.
Lo sé porque lo tuve montado así. La tienda llevaba un módulo que emitía la factura y el albarán, los mandaba al cliente y los dejaba descargables en su área de usuario. Funcionaba. Pero la factura que valía para la contabilidad era la del ERP, así que había que cuadrar las dos a mano, y cualquier corrección hecha en un lado dejaba al otro mintiendo.
La solución no es sincronizar mejor los dos documentos: es que solo exista uno. Hoy la factura la emite y la envía el ERP —la web solo dispara el proceso—, y el cliente sigue teniendo su listado dentro de su perfil, pero cuando pulsa descargar el PDF viene del ERP. Nadie compara nada, porque no hay dos cosas que comparar. Al cliente no se le quita nada: sigue teniendo sus facturas en su cuenta, y ahora la que se descarga es exactamente la que está en la contabilidad.
Merece la pena decirlo claro porque es contraintuitivo: la mejora no consistió en automatizar más, sino en quitar una pieza. El módulo que emitía facturas en la tienda hacía bien su trabajo; el problema era que hubiera dos emisores. Cuando dos sistemas generan el mismo documento, la conciliación entre ambos no es un descuido que se pueda pulir, es el precio fijo de haberlos duplicado.
Cómo lo monto
El orden que evita rehacerlo dos veces.
- Primero se decide quién emite: la tienda o el ERP, uno de los dos. Si ya hay un módulo de facturación en la tienda, esto significa retirarlo, y es lo mejor que se puede hacer por el proyecto.
- Después, el momento de la factura, con el flujo de pedidos delante y sabiendo cuántos se cancelan después de pagados. Es la decisión que más caro sale cambiar luego.
- Se prueba con pedidos reales pequeños antes de abrir el grifo, incluyendo un reembolso parcial a propósito. Ese caso no aparece en las pruebas de nadie y es el que falla.
- Se monta un recuento que compare pedidos facturables y facturas emitidas del mismo periodo. Si un día dejan de cuadrar, quiero enterarme yo, no en el trimestre.
- Se deja escrito qué queda fuera: compras, conciliación y cierre. Por escrito, para que nadie dé por hecho que estaba incluido.
Me pasas la URL de tu tienda y te contesto con tres cosas concretas, sin coste y sin llamada.