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 es registro de facturas y tesorería, no contabilidad societaria |
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. Pero una factura sin identificación fiscal del cliente es una factura coja, y quien la pide después —siempre hay quien la pide— se encuentra con que hay que rehacerla. 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?
Esto importa antes de prometerle nada a nadie, porque marca la frontera entre lo que se automatiza de verdad y lo que va a seguir haciéndose a mano por mucho presupuesto que se le eche.
| Operación | Estado | Detalle |
|---|---|---|
| Leer facturas, contactos y productos | Sí | Sin problema |
| Leer movimientos bancarios y pagos | Sí | Con su estado de conciliación |
| Crear factura de venta | Sí | Es lo que hace la integración |
| Crear factura de compra | No | Existen pedido y albarán de compra, pero no generan gasto ni IVA soportado: no sustituyen a la factura |
| Crear o editar pagos | No | Hay que entrar por la interfaz |
| Sacar un balance por API | No | El listado de cuentas devuelve movimientos del periodo, no saldos acumulados: sumar años no da un balance |
La consecuencia práctica: el circuito de ventas se automatiza entero, y el de compras no. Quien te venda «automatizamos tu contabilidad» sin distinguir esas dos mitades, o no ha llegado a la segunda o no te la 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.