Si tu negocio cobra en cuotas o suscripciones a través de GoHighLevel, hay una pregunta que tu dashboard no responde con confianza: ¿quién está al día de verdad? Entre pagos que fallan y luego se recuperan, cobros manuales que nadie registró y transacciones que viven en la plataforma mientras tu contabilidad vive en otra parte, la foto financiera se degrada en silencio. Este artículo documenta el patrón de reconciliación de pagos que mantengo en producción: un proceso automático que consulta las transacciones de GoHighLevel, deriva el estado real de cada cliente y se corrige a sí mismo en cada corrida.
Respuesta rápida
- El problema: el estado de pago de un cliente no es un dato que se anota una vez, es una conclusión que cambia con cada transacción; anotarlo a mano garantiza desincronización.
- La fuente: el endpoint de transacciones de la API de GoHighLevel (con
altId+altType=location, uno de sus quirks), consultado por contacto. - El modelo: derivar el estado desde los hechos: pago exitoso = al día; pago fallido = atrasado, SALVO que exista un cobro posterior exitoso (entonces el fallo quedó perdonado).
- Las propiedades: idempotente (correr dos veces no duplica nada) y auto-sanadora (cada corrida completa reconverge el estado total).
- La cobranza automática va aparte y apagada por defecto: primero meses de datos correctos, después automatizar consecuencias.
| Hecho en las transacciones | Estado derivado | Por qué |
|---|---|---|
| Último cobro exitoso | Al día | El dinero llegó; no hay discusión |
| Cobro fallido sin éxito posterior | Atrasado | El fallo sigue vivo |
| Cobro fallido con éxito posterior | Perdonado (al día) | El cliente ya resolvió; castigarlo sería un falso positivo |
| Sin transacciones en el período | Según contrato | Ausencia de datos no es morosidad |
La palabra clave del modelo es «derivar»: el estado nunca se escribe a mano, siempre se calcula desde los hechos.
Por qué los estados anotados a mano siempre terminan mal
El flujo típico sin reconciliación: alguien del equipo marca «pagado» cuando ve el cobro, «moroso» cuando ve el fallo, y la realidad se les escapa por los bordes. El pago que falló el lunes y se recuperó el miércoles queda como moroso para siempre. El cobro manual por transferencia nunca entra al sistema. El cliente que pausó y retomó vive en un limbo de etiquetas contradictorias. A los seis meses, nadie confía en el dato y las decisiones de cobranza se toman llamando a contabilidad.
La causa de fondo no es descuido: es que el estado de pago es una función del historial de transacciones, y las funciones no se anotan, se calculan. Cada vez que el historial cambia (nuevo cobro, nuevo fallo, recuperación), la conclusión puede cambiar. Un humano no puede recalcular eso por cliente cada día. Un proceso sí, y GoHighLevel expone justo lo necesario para hacerlo.
¿Cómo se reconcilian los pagos de GoHighLevel con una base externa?
La reconciliación consulta periódicamente las transacciones de cada contacto en la API de GoHighLevel y deriva su estado de pago con reglas explícitas: el cobro exitoso marca al día, el fallido marca atrasado salvo que exista un cobro posterior exitoso, y todo se escribe de forma idempotente en la base externa, que queda como fuente confiable para reportes y cobranza.
Esfuerzo real de implementación:
- Consulta de transacciones + escritura idempotente: 1 o 2 jornadas.
- Modelo de estados completo con reglas de perdón y convergencia: 1 jornada adicional.
- Conexión con workflows de cobranza (opcional y al final): media jornada.
El patrón, pieza por pieza
1. La consulta: transacciones por contacto, con su quirk incluido
El endpoint de transacciones de pagos pertenece a la generación de la API que identifica la subcuenta con altId + altType=location en lugar del locationId habitual: enviarlo mal produce el clásico error de «location requerido» con el location enviado. Es uno más de los quirks documentados de la API; encapsulado en el cliente HTTP, desaparece del resto del código. La consulta corre por contacto activo y trae el historial que alimenta todo lo demás.
2. El modelo failure-driven: los fallos mandan, con derecho a perdón
La regla central del modelo que opera en producción: un cobro fallido marca atraso salvo que exista un cobro exitoso posterior. Ese «salvo» es la diferencia entre un sistema útil y una fábrica de falsos positivos: los reintentos de tarjeta se recuperan solos constantemente, y cobrarle la etiqueta de moroso a quien ya pagó destruye la confianza en el dato (y la relación, si la cobranza automática actúa sobre él). El estado «perdonado» existe explícitamente en el modelo: registra que hubo fallo y que quedó resuelto, lo que además deja rastro útil para detectar clientes con patrón de fallos recurrentes.
3. Idempotencia y convergencia: el proceso que se corrige solo
Cada corrida escribe por referencia de transacción (idempotente: procesar dos veces el mismo cobro no duplica nada) y termina con un barrido de convergencia que recalcula el estado de todos los contactos tocados. La consecuencia práctica es la propiedad más valiosa del sistema: es auto-sanador. Un bug corregido, una corrida interrumpida, un dato manual mal metido: la siguiente pasada completa deja el estado global consistente sin intervención. En sistemas financieros pequeños, esa propiedad vale más que cualquier dashboard, porque elimina la categoría entera de «hay que revisar por qué esto quedó mal».
4. La cobranza automática: apagada por defecto, y es una decisión de diseño
El paso final tentador: si ya sé quién está atrasado, que el sistema lo meta solo al workflow de cobranza de GoHighLevel (la API permite añadir y sacar contactos de workflows programáticamente). Mi implementación lo soporta y lo mantiene detrás de un flag apagado por defecto, y esa decisión es deliberada: primero el sistema demuestra durante semanas que sus estados son correctos, después se le da el poder de enviarle mensajes de cobro a clientes reales. Un recordatorio de pago enviado al cliente equivocado cuesta más que toda la automatización. El orden correcto siempre es: datos confiables, luego consecuencias automáticas.
Cuándo NO montar esto
Si cobras pagos únicos sin cuotas ni recurrencia, la reconciliación es maquinaria sin problema que resolver: el reporte nativo de pagos de GoHighLevel te alcanza. El patrón se justifica con recurrencia, planes en cuotas, volumen de clientes o cobros mixtos (plataforma + manuales), que es donde los estados anotados a mano colapsan. Una referencia de escala: el patrón vale la pena desde unas decenas de clientes en cuotas; por debajo, una revisión semanal disciplinada sobre el reporte nativo aguanta. Y requiere plan con API, como todo lo serio de integración: Unlimited hacia arriba.
Errores comunes
- Marcar moroso al primer fallo sin regla de perdón: los reintentos recuperados llenan tu base de falsos morosos y tu cobranza de disculpas.
- Escribir estados sin referencia de transacción: sin idempotencia, cada corrida repetida duplica o pisa; el histórico se vuelve ruido.
- Automatizar la cobranza el primer día: consecuencias automáticas sobre datos no validados es la receta del incidente con clientes.
- Ignorar los cobros manuales: si existen transferencias fuera de la plataforma, necesitan su vía de entrada al modelo o serán morosidad fantasma.
- Confiar en webhooks como única fuente: el webhook avisa rápido pero puede perderse; la consulta periódica reconciliadora es la que garantiza completitud.
Preguntas frecuentes
La API v2 incluye endpoints de transacciones, pagos y facturas por subcuenta, consultables por contacto. La particularidad técnica: esta familia identifica la subcuenta con altId y altType=location en lugar del locationId habitual del resto de la API.
Diaria es el estándar que mantengo para cuotas y suscripciones: equilibra frescura del dato con consumo de API. Operaciones con cobros intradía intensivos pueden bajar a horaria; el diseño idempotente hace que la frecuencia sea un ajuste, no una reescritura.
No: la alimenta. La reconciliación mantiene el estado operativo (quién está al día para efectos de servicio y cobranza); la contabilidad formal sigue en tu sistema contable. La base externa reconciliada es el puente confiable entre ambas.
Sí: la reconciliación lee las transacciones registradas en GoHighLevel independientemente del procesador de fondo. Si además cobras por vías que nunca tocan la plataforma, esas necesitan su registro manual o su integración aparte para que el modelo vea el cuadro completo.
Los custom fields pueden almacenar el estado final, y de hecho conviene escribirlo de vuelta para que el equipo lo vea en el CRM. Pero el cálculo (historial, reglas, convergencia, auditoría de cambios) necesita una base real: hacerlo con workflows sobre custom fields es forzar a la plataforma a ser lo que no es, con costo por ejecución incluido.
Patrón descrito desde un sistema propio en producción reconciliando pagos reales, verificado a julio de 2026. Si tu operación cobra recurrente sobre GoHighLevel y el «quién está al día» todavía es una hoja de cálculo, este es exactamente el tipo de sistema que implemento.
La idea que sostiene todo
Un negocio de cobros recurrentes tiene dos versiones de la verdad: lo que el equipo cree y lo que las transacciones dicen. La reconciliación automática no es un lujo técnico: es la decisión de que mande la segunda. Todo lo demás (el modelo de estados, la idempotencia, el perdón, la convergencia) es ingeniería al servicio de una idea simple: que la pregunta «¿quién nos debe?» tenga una respuesta que nadie tenga que dudar. Los sistemas financieros confiables no se construyen anotando mejor. Se construyen dejando de anotar, y dejando que el proceso que nunca se cansa haga el trabajo que a los humanos se nos escapa por los bordes.
