El socio paga en ventanilla y el asiento ya está hecho

En casi toda cooperativa hay dos verdades sobre la misma plata.

Una vive en el sistema de operación: los socios, los créditos, los pagos que entraron hoy por ventanilla. La otra vive en la contabilidad: el balance, el estado de resultados, lo que se le enseña al consejo de vigilancia y al ente que regula.

Entre esas dos verdades casi siempre hay una persona transcribiendo. A fin de mes alguien se sienta con los reportes de la operación y arma los asientos a mano, uno por uno. Es trabajo que no agrega nada —el dato ya existe, solo está del otro lado— y es exactamente donde se cuelan las diferencias que después nadie encuentra.

RAILCOOP y CAF están conectados justamente para que esa persona no tenga que existir.

El asiento nace con la operación, no al final del mes

Cuando el cajero registra un pago, el asiento contable se arma en ese momento, como parte de la misma operación. No es un proceso nocturno que después recoge lo del día ni una exportación que alguien tiene que acordarse de correr: es parte de registrar el pago.

Lo mismo con un desembolso, con la apertura de caja, con un traslado a bóveda. La operación y su reflejo contable son un solo acto.

Y de ahí el asiento viaja a CAF, que es donde vive la contabilidad de verdad: los libros, los estados financieros, las declaraciones.

Un pago no es una sola línea

Acá está la parte que más trabajo manual ahorra, y la que más se subestima.

Cuando un socio abona a su crédito, ese dinero no es una cosa sola. Una parte amortiza capital, otra parte paga los intereses corridos, y si venía atrasado, otra parte es mora. Contablemente son tres destinos distintos: el capital reduce la cartera, los intereses y la mora son ingresos.

Un recibo de Q1,200 puede ser Q900 de capital, Q260 de interés y Q40 de mora. El que transcribe a mano tiene que abrir el detalle del pago, hacer esa separación y escribir tres o cuatro líneas. Por cada recibo. Todos los días.

El sistema ya sabe cómo se descompuso ese pago —lo calculó él al aplicarlo— así que arma el asiento con sus líneas separadas: la caja o el banco por lo que entró, la cartera por el capital, y las cuentas de ingreso por interés y mora, cada una por su monto. Si en ese pago no hubo mora, esa línea sencillamente no aparece.

El desembolso sabe a qué cuenta de cartera va

"Cartera" no es una cuenta. Es un árbol.

En el catálogo de una cooperativa la cartera se abre por estado —vigente, vencida— y dentro de cada uno por tipo de crédito y por tipo de garantía: fiduciaria, prendaria, hipotecaria. Un desembolso hipotecario vigente y uno fiduciario vencido no van al mismo lugar, aunque los dos sean "cartera".

Cuando se entrega un crédito, el sistema resuelve esa cuenta contra el catálogo real de esa cooperativa, no contra una tabla ideal. Busca la hoja específica que corresponde a ese estado, tipo y garantía; si esa cooperativa no la tiene abierta, sube al nivel padre más cercano que sí exista.

Con una condición que importa: ese padre tiene que seguir siendo cartera. El sistema nunca sube tanto como para terminar contabilizando contra "Activo" a secas, ni inventa un código que el catálogo no tenga. Si de plano no hay ninguna cuenta de cartera donde aterrizar, el desembolso no genera un asiento fantasma que descuadre el balance en silencio: queda marcado para que alguien lo revise.

El dato que convierte una estimación en una regla

Este salió de una petición del contador, y es de los cambios chiquitos que cambian un día de trabajo.

La cartera hay que clasificarla entre corto y largo plazo para el balance. Eso depende del plazo del crédito, no del monto ni del tipo. Y el plazo era justamente el dato que no cruzaba: al asiento le llegaba la fecha, el concepto, la referencia y los montos, pero no las condiciones del crédito que lo originó.

Resultado: para clasificar, el contador tenía que ir al otro sistema y abrir crédito por crédito.

Ahora el desembolso viaja con sus condiciones: el plazo en meses, cada cuánto paga, la fecha de vencimiento, el tipo de crédito y el tipo de garantía. La clasificación deja de ser un criterio que se aplica a ojo y pasa a ser una regla que se aplica sola, igual todas las veces, y que se puede auditar después.

Solo los desembolsos llevan esa información. Un pago o un depósito no la necesitan y no la cargan.

La fecha del hecho, no la del día que se digitó

Un detalle que descuadra periodos enteros: la fecha del asiento es la de la operación, no la del día en que se capturó.

Si un crédito se desembolsó en febrero y se cargó al sistema en agosto, el asiento queda en febrero, que es cuando pasó. Y en CAF también, porque es el mismo dato el que viaja. Sin esto, un rezago de captura ensucia dos meses: el que no registró lo que sí ocurrió y el que registró lo que no.

Con el mismo criterio, las provisiones de fin de mes quedan fechadas al cierre del mes que les toca, aunque el proceso que las genera corra el día 1 del mes siguiente. La provisión de junio dice junio.

Que las dos aplicaciones se hablen por red implica que la red falla

Un envío entre dos sistemas no puede ser "disparar y olvidar". Si CAF no responde en ese instante —mantenimiento, un corte, lo que sea— el asiento no puede quedar dependiendo de que alguien se dé cuenta.

Por eso cada asiento queda con su estado visible: sincronizado o pendiente de envío. Los que quedan pendientes entran a una cola, y el mismo proceso diario que ya corre los cálculos de la cooperativa la vacía al final: reintenta los que faltan y recoge los que por cualquier razón nunca entraron.

La diferencia práctica es que "no llegó" es un estado que se ve y se resuelve solo, en vez de un silencio que se descubre tres meses después cuadrando el balance.

Lo que gana la cooperativa

La contabilidad de una cooperativa no debería ser un segundo trabajo que se hace después del trabajo. Si el dato ya está bien capturado en la operación, el asiento es una consecuencia — no una tarea.

¿Tu cooperativa todavía arma los asientos a mano al cierre de cada mes? Escribinos por WhatsApp y te mostramos cómo quedó conectado.