Finanzas
Conciliación financiera
Automatiza la conciliación bancaria, de tarjetas, del SII y de Buk contra la contabilidad, con excepciones bajo control y registro revisable de cada ejecución.
En resumen
Un módulo de agentes de IA gobernados que toma los movimientos bancarios, las liquidaciones de tarjetas, los documentos tributarios del SII y las centralizaciones de remuneraciones de Buk, y los cruza contra el sistema contable de registro (Odoo, NetSuite, SAP). Resuelve la larga cola de calces difusos con un LLM bajo una política explícita y deja para el contador solo los casos que no se pueden resolver. Cada vínculo, cada descarte y cada anotación queda en un registro de auditoría inmutable y vuelve al ERP con el usuario del operador.
La conciliación bancaria, de tarjetas, tributaria y de remuneraciones es el eslabón más lento y propenso a errores del cierre mensual. Las cartolas llegan en formatos distintos, los procesadores de tarjetas agrupan varios días de ventas en un solo abono, el SII publica documentos a su propio ritmo y las centralizaciones de remuneraciones entran como asientos compuestos. La mayoría de los equipos lo resuelve a mano, en planillas y contra el reloj.
El módulo de conciliación financiera opera cuatro agentes de IA gobernados, uno por fuente (banco, tarjetas, SII, Buk). Cada uno entrega una decisión tipificada —vincular, descartar o dejar pendiente— junto con la evidencia que la respalda. Las reglas deterministas despejan los calces evidentes, la capa de agentes resuelve los difusos dentro de límites de política explícitos y la persona revisa solo las excepciones.
La plataforma nunca contabiliza en el ERP sin una aprobación registrada. Cada vínculo es reversible, cada decisión de un agente se puede desplegar en las llamadas a herramientas que la originaron y el registro de auditoría se puede exportar para los auditores externos y las revisiones del SII.
Qué resuelve este caso
En una operación chilena mediana típica, cerrar un solo mes implica cuatro frentes de conciliación —banco, tarjetas, SII y Buk—, cada uno con su propio formato, ritmo y casos borde. El equipo pasa días copiando y pegando entre planillas y el ERP, y la larga cola de calces difusos (un abono que agrupa tres facturas, una liquidación de tarjeta neta de comisiones, una boleta de honorarios que aparece en el SII 48 horas después) se lleva la mayor parte del esfuerzo.
El OCR genérico y los conciliadores basados en reglas resuelven la mitad fácil y fallan en silencio con el resto. Lo que la operación realmente necesita es un sistema que combine reglas deterministas para los casos de alta confianza, una capa de agentes que proponga resoluciones para los ambiguos con evidencia trazable y una cola humana para lo que quede, todo bajo un mismo registro de auditoría, de modo que los auditores externos y el SII puedan reconstruir cualquier decisión después.
Para quién es
- Gerencias de finanzas de empresas medianas y grandes que operan en Chile y la región andina
- Organizaciones con operación multibanco y multimoneda sobre un único ERP
- Centros de servicios compartidos que consolidan la contabilidad de varias razones sociales
Cómo funciona
Un patrón de referencia usa procesos separados para banco, tarjetas, SII y remuneraciones, dentro de un único flujo controlado. Los permisos se limitan a los registros necesarios. Las escrituras requieren aprobación del operador y usan identidad delegada cuando el sistema lo permite, o una cuenta de servicio con privilegios mínimos en caso contrario.
- DatosIngesta de fuentes y estado del ERPToma las cartolas bancarias diarias (conectores tipificados por banco), los archivos de liquidación de tarjetas, los libros del SII (compras, ventas y honorarios), las centralizaciones de Buk y el estado contable abierto del ERP. Solo lectura.
- AutomatizaciónAplicación de reglas de calce deterministasLos calces por monto exacto, fecha exacta y número de referencia se despejan sin intervención del LLM. Aquí se resuelve el grueso de la actividad rutinaria (típicamente entre 60 % y 80 %), y nada sale de esta fase sin una fuerza de calce registrada.
- AgenteResolución de casos difusos bajo políticaPara las partidas sin calce, el agente de conciliación propone un vínculo o un motivo de descarte tipificado. Cada propuesta cita las filas de origen de ambos lados, la regla que la marcó y la cláusula de política que permite la resolución. Si la confianza queda bajo el umbral configurado, la partida pasa a la cola de excepciones.
- PersonaRevisión de excepciones por el operadorEl contador ve en la consola de Xophia solo la cola sin resolver: las filas de origen lado a lado, la acción que propone el agente y un botón para aprobar, editar o rechazar. Las operaciones masivas (por ejemplo, aprobar todas las liquidaciones netas de comisión del procesador X) están integradas desde el diseño.
- AutomatizaciónAplicación, contabilización y auditoríaLas acciones aprobadas se escriben en el ERP a través del conector con el usuario del operador. Cada acción genera una fila de auditoría inmutable: identificadores de origen de ambos lados, id de traza del agente, cláusula de política, id del operador y marca de tiempo. La máquina de estados de la conciliación avanza y la fila de auditoría se puede exportar para el auditor externo y el SII.
Sistemas que conecta
- Odoo / NetSuite / SAPERP (sistema de registro)
- BCI · Santander · Itaú · BancoEstado · Banco de ChileConectores de cartolas bancarias
- Cardda · Transbank · WebpayConectores de liquidación de tarjetas
- SIIDocumentos tributarios (compras, ventas, honorarios)
- BukCentralización de remuneraciones
- Registro de auditoría de XophiaCumplimiento y auditoría externa
Metas de referencia
| Indicador | Antes | Meta |
|---|---|---|
| Tasa de calce automáticoCantidad de filas de origen resueltas por regla determinista o por propuesta aprobada del agente, dividida por el total de filas conciliables del período. | Entre 40 % y 55 % de las partidas calzadas sin intervención humana | ≥ 85 % calzado automáticamente (reglas + agente), dentro del umbral de confianza configurado |
| Tiempo para despejar el cierre de mesDesde que se ingieren todos los archivos de origen del período hasta que el 100 % de las partidas queda en un estado terminal (calzada, descartada o escalada). | Entre 5 y 10 días hábiles después del cierre del período | ≤ 2 días hábiles después del cierre del período |
| Antigüedad de las excepciones pendientesDistribución de (ahora − exception_created_at) sobre las partidas en la cola de excepciones, medida a diario. | Colas de varias semanas son habituales | p95 de antigüedad de excepciones ≤ 3 días hábiles |
| Completitud de la auditoríaControl sobre el registro de auditoría: cada vínculo, desvínculo, descarte y contabilización debe referenciar ambas filas de origen y un id de operador; cualquier brecha dispara una alerta de cumplimiento. | Planillas ad hoc y trazas parciales | 100 % de las transiciones de estado vinculadas a una fila de auditoría con identificadores de origen, política y operador |
Valores de un escenario ilustrativo, no resultados de clientes.
Traza de ejecución ilustrativa
Un ejemplo sintético de cómo podría quedar registrada una conciliación. Nombres, identificadores, volúmenes, costos y resultados son ficticios; la secuencia es ilustrativa y no corresponde a un resultado de cliente.
Ejecución diaria para la razón social LE-02. La cartola bancaria trae 47 movimientos. Las reglas deterministas despejaron 31; el agente propuso resoluciones para 14 y derivó 2 a la cola de excepciones.
| Herramienta | Entrada | Salida |
|---|---|---|
| bank.list_statement_movements | entity_id=LE-02, account=CL-BCI-1234, date=2026-05-04 | 47 movimientos, monto total CLP 184.520.330 |
| erp.list_open_invoices | entity_id=LE-02, status=posted, payment_state=not_paid, currency=CLP | 212 facturas candidatas dentro de la ventana de calce |
| rules.deterministic_match | movements=47, candidates=212, tolerance=CLP 1 | 31 calces exactos, 16 sin resolver (12 por monto parcial, 3 agrupados con comisión, 1 reverso) |
| agent.propose_resolution | movement_id=BM-9087, signals=['fee_aggregated','same_processor'] | Propone vincular con las facturas INV-3041 e INV-3052, netas de CLP 12.400 de comisión del procesador. Confianza 0,93. Política: card_processor.cardda.allow_fee_aggregation |
| agent.flag_exception | movement_id=BM-9112, signals=['no_candidate','amount_mismatch'] | No hay factura abierta que calce dentro de una ventana de ±5 días. Derivado a la cola de excepciones con priority=normal. |
| console.publish_digest | operator_id=ACC-04, items=16 (14 propuestas, 2 informativas) | digest_id=R-2026-05-05-LE-02-BCI pendiente de revisión |
El operador aprobó 13 propuestas y editó 1 a las 09:42 UTC; la excepción restante se escaló al contralor. Las partidas aprobadas se contabilizaron en Odoo como bank.statement.line.reconcile con el usuario del operador. Fila de auditoría R-2026-05-05-LE-02-BCI cerrada. Costo total del agente: USD 0,078; latencia p95: 8,4 s.
¿Te sirve este módulo?
En 20 minutos revisamos cómo se vería sobre tus sistemas.