La conciliación bancaria es, en la práctica, el proceso contable que más tiempo consume y más frecuentemente retrasa el cierre mensual en empresas medianas peruanas. Cada mes, el equipo contable descarga extractos PDF de BCP, BBVA, Scotiabank, Interbank y Banco de la Nación; exporta el libro auxiliar del ERP; y abre Excel para el cruce manual: movimiento por movimiento, columna por columna, buscando la partida que no cierra, la comisión que falta registrar, la detracción que llegó a la cuenta especial del Banco de la Nación. En empresas con 3 a 6 cuentas bancarias y varios cientos de movimientos mensuales, este proceso consume entre 2 y 5 días-persona al mes, con tasas de error estimadas entre el 3% y el 8%, y retrasos que empujan el cierre contable hasta los 15 días hábiles.
Lo que hace especialmente complejo el problema en Perú no es solo el volumen, sino las particularidades del ecosistema bancario local. Cada banco tiene su propio formato de extracto PDF; los depósitos de detracciones SPOT van a una cuenta especial del Banco de la Nación que debe conciliarse de forma independiente; el ITF del 0.005% aparece en cada movimiento del extracto pero no siempre tiene su contrapartida en el asiento original; y las transferencias interbancarias usan el CCI como referencia que el sistema debe aprender a identificar. Los tutoriales globales sobre conciliación automatizada no contemplan ninguna de estas particularidades.
La combinación de OCR para leer extractos bancarios en PDF, RPA para automatizar el matching de movimientos contra el ERP, e IA para clasificar excepciones y aprender patrones cambia radicalmente el escenario: tasas de auto-conciliación del 85-97%, tiempo de supervisión reducido a 2-4 horas, y cierre mensual acelerado a 3-5 días hábiles. Este artículo explica cómo funciona esa arquitectura, cómo se integra con los ERPs más usados en Perú y cómo implementarla en fases sin reemplazar el sistema contable actual.
Por Qué la Conciliación Bancaria Manual es un Cuello de Botella en Perú
Tiempo y error: cifras en empresas medianas peruanas
El flujo manual típico tiene seis pasos: descarga de extractos bancarios en PDF o Excel desde la banca en línea, exportación del libro auxiliar de bancos desde el ERP, importación de ambos archivos a Excel, cruce columna por columna con fórmulas BUSCARV o coincidencia aproximada, identificación y documentación de partidas abiertas, y revisión final del responsable contable antes que el gerente financiero apruebe el cierre.
Cada paso introduce fricciones. Los extractos de cada banco tienen estructura diferente: BCP lista las columnas en un orden, Scotiabank en otro, Banco de la Nación agrega columnas de número de operación que los demás no incluyen. La exportación del ERP varía según la versión instalada. Las fórmulas de Excel fallan cuando una descripción bancaria cambia mínimamente (un espacio, un carácter especial, una abreviatura distinta). El resultado es que la conciliación bancaria se convierte en el cuello de botella que bloquea todas las actividades de cierre posteriores: cuentas por cobrar, cuentas por pagar y estados financieros no pueden cerrarse hasta que la conciliación bancaria esté completa.
Particularidades del ecosistema bancario peruano
| Particularidad | Descripción | Impacto en matching |
|---|---|---|
| Detracciones SPOT | Depósitos obligatorios en cuenta especial del Banco de la Nación | Requieren flujo de conciliación separado del libro de bancos principal |
| ITF (0.005%) | Aparece en cada movimiento del extracto bancario | Debe tolerarse automáticamente como gasto; no genera excepción |
| Tipo de cambio SBS | Diferencia entre TC del día del registro y TC del día del pago | Categoría de partida sistemática configurable |
| CCI en transferencias | Código de Cuenta Interbancario como referencia de la operación | El motor debe extraerlo del descriptor y usarlo como clave de matching |
| Formatos propios por banco | BCP, BBVA, Scotiabank, Interbank y BN tienen estructuras PDF distintas | Requiere plantilla OCR específica por banco |
| Liquidaciones de POS | Niubiz/GetNet depositan neto con comisión descontada | Matching N-a-1: varias ventas contra un depósito neto |
Anatomía de la Solución: OCR + RPA + IA
La arquitectura se organiza en tres capas que operan en secuencia. Cada capa resuelve un problema distinto y el resultado de una alimenta la siguiente.
Capa 1: OCR/IDP para Extracción de Movimientos Bancarios
El módulo OCR recibe el extracto bancario en PDF (descargado de la banca en línea o enviado por el banco) y extrae la tabla de movimientos: fecha, descripción, cargo, abono y saldo. El desafío no es solo reconocer el texto, sino entender la estructura tabular de cada banco, que varía en número de columnas, posición de encabezados y formatos de fecha.
Las plantillas OCR se configuran por banco, no por documento. Una vez que el sistema tiene la plantilla de BCP, todos los extractos futuros de BCP se procesan con la misma regla sin intervención humana. El módulo también normaliza los datos extraídos: fechas al formato estándar, importes al formato numérico consistente, y descriptores bancarios al texto limpio sin caracteres especiales.
Capa 2: Motor de Matching Automático con Tolerancias
El motor RPA toma los movimientos extraídos del extracto y los registros del libro auxiliar exportados del ERP, y ejecuta los algoritmos de matching en orden de prioridad:
- Coincidencia exacta (1-a-1): un movimiento bancario coincide con un asiento contable en fecha, importe y referencia. Es el caso más simple y de mayor volumen en empresas con buenas prácticas de registro.
- Matching con tolerancia: el importe difiere en menos de un umbral configurable (por ejemplo, diferencias de ITF, redondeo de céntimos o comisiones bancarias conocidas). El motor concilia automáticamente y registra la diferencia como gasto financiero.
- Matching N-a-1: varios movimientos bancarios (pagos parciales) corresponden a un solo asiento contable. Frecuente en cuotas de crédito o pagos en partes.
- Matching 1-a-N: un solo depósito bancario (liquidación de pasarela de pago) corresponde a múltiples facturas o asientos. Frecuente en e-commerce con pasarelas como Culqi o Mercado Pago.
Las tolerancias se configuran antes del piloto y se refinan con datos históricos: diferencia de ITF, comisión de mantenimiento de cuenta, diferencia de redondeo (hasta S/ 0.10), diferencia de fecha (hasta N días hábiles para cheques o transferencias interbancarias con demora).
Capa 3: IA para Clasificación de Excepciones y Aprendizaje
Los movimientos que el motor RPA no pudo conciliar automáticamente pasan a la capa de IA, que los clasifica según el tipo de excepción y sugiere una acción:
- Movimiento en banco sin asiento en ERP: probablemente un cargo no registrado (comisión, débito automático, pago a proveedor no contabilizado aún).
- Asiento en ERP sin movimiento en banco: probablemente un cheque emitido y no cobrado, o una transferencia en tránsito.
- Diferencia de importe: puede ser una diferencia de tipo de cambio, una comisión no prevista, o un error de registro.
- Diferencia de fecha: transferencia interbancaria con demora o fecha de valor distinta a fecha de operación.
La IA también aprende los patrones de descriptores bancarios con el tiempo. Por ejemplo, aprende que “COMI MANT CTA CTE” es siempre la comisión de mantenimiento de cuenta del BBVA y debe tolerarse automáticamente, o que “DETRAC SPOT” en el descriptor del Banco de la Nación corresponde a un depósito de detracción y debe redirigirse al flujo de conciliación de la cuenta SPOT.
Algoritmos de Matching y Manejo de Excepciones
Tipos de Matching y Tolerancias Configurables
| Tipo de matching | Caso de uso típico en Perú | Tolerancia recomendada |
|---|---|---|
| Exacto 1-a-1 | Transferencias bancarias con referencia clara | Sin tolerancia |
| Con tolerancia de importe | Pagos con ITF, redondeos, comisiones conocidas | ITF calculado + S/ 0.10 |
| N-a-1 (varios a uno) | Pagos en cuotas de crédito; cheques parciales | Suma dentro del ±1% del total |
| 1-a-N (uno a varios) | Liquidación de pasarela de pagos vs. facturas individuales | Importe neto de comisión |
| Por referencia (CCI/número de operación) | Transferencias interbancarias | Coincidencia exacta de referencia |
| Fecha diferida | Cheques emitidos no cobrados; transferencias en tránsito | Hasta 5 días hábiles |
Workflow de Resolución de Excepciones
Las excepciones no resueltas automáticamente siguen un workflow estructurado:
- Clasificación automática por tipo (sin asiento, sin movimiento, diferencia, anomalía).
- Asignación al responsable según el tipo: diferencias de importe al contador de bancos, movimientos desconocidos al tesorero, anomalías al jefe de contabilidad.
- Plazo de resolución configurable por tipo (por ejemplo, 24 horas para movimientos sin asiento, 48 horas para diferencias de tipo de cambio).
- Escalamiento automático si el plazo vence sin resolución.
- Registro de la resolución con evidencia adjunta (comprobante, correo de confirmación del banco, nota de débito).
La detección de anomalías incluye pagos duplicados (mismo importe, mismo beneficiario, misma fecha o fechas contiguas), transferencias circulares entre cuentas propias, y movimientos fuera de horario hábil o por importes inusuales respecto al historial de la cuenta.
Integración con ERPs Populares en Perú
La integración con el ERP es el componente que más varía entre implementaciones y el que más impacta en el tiempo de cierre mensual. No existe un enfoque único: la elección depende del ERP, su versión, y si expone interfaces programáticas.
CONCAR: Importación por Archivo Plano
CONCAR es el ERP contable más usado en empresas medianas peruanas. La integración más común es mediante archivo plano en formato texto delimitado: el motor de conciliación exporta los asientos de ajuste en el formato que CONCAR acepta para importación, y el área contable los valida antes de aprobar la importación. Es la integración menos técnica pero requiere un paso manual de validación que puede automatizarse parcialmente con RPA sobre la UI de CONCAR.
Contasis y Starsoft: Base de Datos o CSV
Contasis y Starsoft exponen sus datos mediante acceso directo a la base de datos (SQL Server en la mayoría de instalaciones) o exportación a CSV. El motor de conciliación puede leer directamente la tabla de libro auxiliar de bancos mediante una consulta SQL, lo que elimina el paso de exportación manual. Requiere coordinación con el proveedor del ERP para asegurar que el esquema de base de datos no cambia entre versiones.
Odoo: API JSON-RPC
Odoo expone una API JSON-RPC nativa que permite leer y escribir asientos contables sin acceder a la base de datos directamente. Es la integración más limpia técnicamente: el motor consulta los movimientos del diario de bancos vía API, ejecuta el matching, y publica los asientos de ajuste como borrador en Odoo para que el contador los confirme. Compatible con Odoo 14, 15, 16 y 17.
SAP Business One: DI Server o API REST
SAP Business One ofrece dos vías: el DI Server (Data Interface Server, disponible en instalaciones on-premise) y la API REST de SAP B1 Service Layer (disponible desde la versión 9.3 y recomendada para integraciones nuevas). La integración por Service Layer es más estable y no requiere instalar componentes adicionales en el servidor.
Criterios para Elegir el Tipo de Integración
La integración directa por API es la opción preferida cuando el ERP la soporta: mínimo mantenimiento, sin dependencia de formatos de archivo, con trazabilidad nativa. RPA sobre la UI del ERP es la alternativa cuando no existe API ni formato de exportación estructurado: más frágil ante actualizaciones de la interfaz, pero no requiere modificar el ERP. La integración por archivo intermedio (ETL) es el enfoque más portable y compatible con cualquier ERP, pero agrega un paso de transformación que debe mantenerse cuando cambia el formato del ERP o del motor de conciliación.
Comparativa de Enfoques y Herramientas
| Enfoque | Tasa de auto-conciliación | Audit trail | Costo mensual estimado (USD) | Complejidad de implementación | Mantenimiento |
|---|---|---|---|---|---|
| Excel avanzado + Power Query | 30-50% | Bajo (manual) | < 50 | Bajo | Alto (fórmulas frágiles) |
| RPA puro (UiPath, Power Automate) | 70-85% | Medio | 300-800 | Medio | Medio (bots se rompen con cambios de UI) |
| Software especializado (Blackline, Trintech, ReconArt) | 90-97% | Alto (nativo) | 1,500-5,000+ | Alto | Bajo |
| Módulos nativos de ERP (SAP, Oracle NetSuite) | 80-92% | Alto | Incluido en licencia ERP | Medio | Bajo |
| Solución custom IDP + orquestador | 85-97% | Alto (configurable) | 400-2,000 | Alto | Medio |
Excel avanzado con Power Query tiene la ventaja del bajo costo inicial, pero no escala más allá de 2-3 cuentas bancarias, no genera pista de auditoría robusta y requiere mantenimiento constante cuando cambian los formatos de extracto. RPA puro (UiPath, Power Automate) es flexible y no requiere API del ERP, pero los bots se rompen cuando el banco actualiza su portal de banca en línea o cuando el ERP cambia su interfaz. Las plataformas especializadas como Blackline o Trintech Cadency son las más completas con mejor audit trail, pero sus costos superan los USD 3,000 mensuales y están diseñadas para empresas grandes con equipos de TI dedicados. La solución custom con IDP y orquestador es la más adecuada para empresas medianas peruanas que buscan un equilibrio entre funcionalidad, costo y adaptabilidad a las particularidades locales.
Casos de Uso por Sub-Sector Peruano
Empresas Comerciales Multi-Banco con Alto Volumen de POS
El desafío principal es conciliar liquidaciones de terminales POS de Niubiz (ex VisaNet) o GetNet contra las ventas diarias registradas en el sistema de punto de venta. Cada liquidación agrupa decenas o cientos de transacciones individuales, descuenta la comisión del adquirente, y deposita el monto neto en la cuenta corriente. El motor debe aplicar matching 1-a-N: un solo depósito neto contra múltiples transacciones de venta, con la comisión registrada automáticamente como gasto financiero.
Constructoras y Contratistas del Estado (SIAF, Detracciones)
Las constructoras que trabajan con el Estado manejan cuentas bancarias separadas por proyecto u obra, y sus detracciones se depositan obligatoriamente en la cuenta especial del Banco de la Nación. La conciliación debe cruzar las transferencias SIAF (del MEF al banco de la empresa) contra las valoraciones de avance de obra registradas en el ERP, y conciliar la cuenta de detracciones de forma independiente. Es el caso con mayor complejidad y mayor ROI de automatización, porque el volumen de excepciones manuales es muy alto.
Sector Financiero No Bancario (AFP, Cajas, Financieras)
Las entidades supervisadas por la SBS tienen conciliación bancaria diaria obligatoria, no mensual. El volumen de movimientos es muy alto y el tiempo disponible para conciliar es mínimo. Estas empresas suelen tener sistemas core bancarios con módulos de conciliación propios, pero el punto de dolor es la integración entre el core bancario y los ERPs generales para el cierre contable consolidado.
Exportadoras e Importadoras (Múltiples Monedas)
Las empresas del sector exportador e importador trabajan con cuentas en soles y dólares, y frecuentemente tienen contratos de forward de cobertura de tipo de cambio que generan asientos de valorización periódica. La diferencia entre el tipo de cambio SBS del día del registro y el del día del pago es una fuente constante de partidas sistemáticas. El motor debe gestionar esta categoría como una regla especial que calcula la diferencia de cambio y la registra según NIC 21 sin generar una excepción manual.
PYMES con E-commerce y Pasarelas Locales
Las PYMES con tienda en línea reciben liquidaciones de Culqi, Mercado Pago Perú, PayPal o Niubiz e-commerce con frecuencia variable: algunas diarias, otras semanales. Cada liquidación agrupa múltiples órdenes de venta, descuenta la comisión de la pasarela, y deposita el neto. El reto es conciliar automáticamente cada orden de venta individual (registrada en el ERP al momento de la venta) contra el depósito neto de la pasarela, con la comisión reconocida como gasto en el momento de la conciliación.
Guía de Implementación en 5 Fases
Fase 1: Diagnóstico (Semanas 1-2)
Actividades: mapeo de todas las cuentas bancarias activas (banco, tipo de cuenta, moneda, volumen mensual de movimientos); identificación de los formatos de extracto de cada banco; relevamiento del ERP (nombre, versión, módulo de bancos, interfaces disponibles); estimación del volumen de movimientos mensuales y distribución por tipo (transferencias, cheques, POS, detracciones, débitos automáticos).
KPIs de validación: lista completa de cuentas bancarias y bancos, muestra de extractos del último trimestre por banco, inventario de interfaces del ERP.
Decisiones clave: qué tipo de integración usar con el ERP (API, base de datos, archivo intermedio, RPA); qué cuentas incluir en el piloto; si las detracciones SPOT tendrán flujo de conciliación propio o compartido.
Fase 2: Piloto (Semanas 3-6)
Actividades: configuración de plantillas OCR para los 2-3 bancos con mayor volumen; carga de 3 meses de datos históricos de extractos y libro auxiliar; ejecución del motor de matching con datos históricos para medir la tasa de auto-conciliación base; ajuste de reglas de tolerancia (ITF, comisiones, redondeos); configuración del workflow de excepciones.
KPIs de validación: tasa de auto-conciliación en datos históricos (objetivo mínimo: 75%); tiempo de procesamiento por mes de datos; número y distribución de excepciones por tipo.
Decisiones clave: si la tasa de auto-conciliación con datos históricos no supera el 70%, revisar la calidad de los datos maestros antes de continuar.
Fase 3: Despliegue Multibancos (Semanas 7-12)
Actividades: extensión de plantillas OCR a todos los bancos restantes; incorporación de todas las cuentas bancarias activas; configuración de reglas específicas por banco (formato de CCI del Banco de la Nación, formato de liquidaciones de POS, detracciones SPOT); capacitación del equipo contable en el workflow de excepciones.
KPIs de validación: tasa de auto-conciliación en operación real (objetivo: ≥ 85%); tiempo de resolución de excepciones; número de excepciones escaladas por semana.
Fase 4: Integración con ERP y Cierre Automatizado (Semanas 13-18)
Actividades: implementación de la integración técnica con el ERP elegido; pruebas de ida y vuelta (el motor lee el libro auxiliar del ERP y devuelve los asientos de ajuste en el formato correcto); automatización de la exportación del libro auxiliar (eliminar el paso manual de descarga); configuración del reporte de cierre (resumen de cuentas conciliadas, partidas abiertas, diferencias pendientes).
KPIs de validación: reducción del tiempo de cierre mensual (objetivo: de 10-15 días a 3-5 días); cero errores de importación de asientos al ERP; reporte de cierre generado automáticamente sin intervención manual.
Fase 5: Mejora Continua con IA (Semanas 19-20+)
Actividades: revisión mensual de los patrones de excepciones para identificar nuevas reglas de matching; entrenamiento del módulo de IA con las resoluciones de excepciones acumuladas; incorporación de nuevos bancos o pasarelas de pago cuando la empresa los adopte; reducción progresiva de la tasa de excepciones manuales.
KPIs de validación: evolución mensual de la tasa de auto-conciliación (objetivo de largo plazo: ≥ 95%); reducción del tiempo de supervisión humana; número de nuevas reglas de tolerancia incorporadas automáticamente por el módulo de IA.
Errores Comunes y Cómo Evitarlos
No estandarizar los datos maestros antes del piloto. Si los proveedores tienen códigos distintos en el ERP y en el extracto bancario, el motor no puede hacer matching por referencia. Audita y limpia los datos maestros (proveedores, clientes, cuentas bancarias) antes de cargar los datos históricos al piloto.
Ignorar las detracciones SPOT como categoría separada. Mezclar los movimientos de la cuenta de detracciones del Banco de la Nación con el libro de bancos principal genera un alto volumen de excepciones irresolubles. La cuenta de detracciones debe tener su propio flujo de conciliación desde el inicio.
No definir las reglas de tolerancia antes del arranque. Sin tolerancias configuradas, el ITF (0.005% de cada movimiento) genera una excepción por cada operación bancaria. El resultado es un sistema que produce más trabajo manual que el que elimina. Define las tolerancias en la fase de diagnóstico con base en el extracto real de cada banco.
Automatizar sin proceso documentado de excepciones. Si el equipo no sabe qué hacer cuando el motor genera una excepción, la lista de partidas pendientes crece indefinidamente. Documenta el proceso de resolución (quién resuelve qué tipo de excepción, en qué plazo, con qué evidencia) antes de activar el sistema en producción.
Olvidar el ITF como partida recurrente. El ITF del 0.005% aparece en el extracto bancario como un cargo independiente por cada débito o crédito, pero no siempre tiene su contrapartida en el asiento contable original. El motor debe reconocerlo automáticamente como gasto financiero sin generar una excepción.
Integraciones frágiles con el ERP sin logs de auditoría. Una integración que no registra qué datos leyó del ERP, cuándo, y qué asientos devolvió es imposible de auditar en una fiscalización. Genera logs detallados con marca de tiempo, usuario de proceso y resultado de cada operación.
Auditoría, Trazabilidad y Valor Legal
Una de las consecuencias menos anticipadas de automatizar la conciliación bancaria es la calidad de la pista de auditoría que genera el proceso. En el esquema manual, la evidencia del control interno es un archivo Excel con fórmulas y quizás una firma en un reporte impreso. En el esquema automatizado, cada movimiento conciliado tiene un registro que indica qué regla de matching se aplicó, qué usuario aprobó la excepción, en qué fecha y hora, y con qué evidencia de respaldo. Esta trazabilidad es superior al control manual en términos de verificabilidad y resistencia a la alteración posterior.
En contexto de fiscalización por parte de SUNAT o de auditoría externa, los logs del motor de conciliación sirven como evidencia del sistema de control interno sobre el proceso bancario. Los auditores pueden verificar que cada movimiento fue revisado, que las excepciones fueron resueltas dentro del plazo definido, y que los asientos de ajuste tienen respaldo documentado.
Los extractos bancarios originales, los reportes de conciliación y los logs del proceso son documentos con obligación de conservación que puede extenderse varios años según el contexto tributario o legal. Cuando la empresa automatiza la conciliación, el volumen de documentos digitales críticos que deben custodiarse correctamente aumenta. AyP Digital, como Organismo de Producción de Microformas certificado por SGS bajo la NTP 392.030-2:2015, puede producir microformas de estos documentos con valor legal equivalente al original bajo el marco del Decreto Legislativo N.° 681, y custodiarlos en la plataforma ePaper. Esto permite al área contable conservar la evidencia del proceso de conciliación con valor probatorio certificable para auditorías o litigios, sin depender del PDF original descargado de la banca en línea.
La Conciliación Bancaria como Habilitador del Cierre Financiero
La conciliación bancaria no es solo un proceso de verificación contable: es la condición necesaria para cerrar el período. Mientras no esté completa, el estado de flujos de efectivo conforme a NIC 7, los saldos de caja en el balance, y los resultados financieros del período permanecen abiertos. Automatizarla con OCR, RPA e IA no es un proyecto de digitalización aislado: es una intervención directa sobre el cuello de botella que determina la velocidad de todo el ciclo financiero mensual. Las empresas peruanas que reducen su cierre de 10-15 días a 3-5 días no lo logran optimizando el proceso de conciliación en Excel, sino reemplazando el cruce manual por un motor que trabaja las 24 horas, aprende de cada excepción resuelta, y entrega al equipo contable solo lo que realmente necesita decisión humana.
