La pregunta está mal planteada: lo que hay que bloquear es la invención
Cada vez que alguien me pregunta si se puede construir un agente de IA para contabilizar facturas de compras sin error, mi respuesta incomoda: depende de qué se entienda por “sin error”. Si significa que ninguna factura volverá a pasar por manos humanas —ni para revisarla, ni para corregirla, ni para aprobarla—, la respuesta honesta es no: siempre habrá documentos ilegibles, proveedores nuevos o cuentas ambiguas que necesiten el criterio de una persona. Si significa cero errores materiales y, sobre todo, cero cifras inventadas, es un objetivo alcanzable y medible.
Esa distinción es criterio de diseño, no eslogan. Un agente contable puede clasificar mal un gasto, dudar entre dos cuentas parecidas o derivar el caso a revisión. Lo que no debería hacer nunca es rellenar un número que no pudo leer. Cuando el modelo no lee bien el total y aun así escribe una cifra plausible, ya no hay un error contable: hay una alucinación con apariencia de asiento. Eso se bloquea por arquitectura, no solo por prompt.
El punto débil real es la lectura, no la contabilidad
En mi experiencia, el error más frecuente al procesar facturas de compra no es de negocio, sino de lectura. El OCR de facturas y cartolas es una fuente de fallo peligrosa porque los números son el dato más sensible de todo el flujo: un proveedor mal escrito se detecta a ojo; un 19.000 convertido en 91.000 puede pasar desapercibido hasta el cierre.
Conviene ser prudente: el acierto por campo que se cita varía según el tipo de documento, el idioma y el motor de OCR, y no existe un número universal. Lo verificable es el efecto de composición: si una cadena depende de varios pasos independientes con acierto p, el acierto conjunto se aproxima a p elevado al número de pasos. Cinco pasos con 99% dan ≈95%; con 95% cada uno, ≈77%. De ahí la conclusión de ingeniería: hay que acortar la cadena y blindarla con verificaciones deterministas.
De dónde sale el dato, en orden de prioridad:
- Dato estructurado nativo (XML/DTE, archivo del proveedor, integración por API).
- Registro de Compras del organismo tributario, cuando esté disponible y sea accesible para el contribuyente.
El OCR no es una fuente de datos en este orden y nunca se usa solo. Es una ayuda adicional que complementa la búsqueda en internet del giro del proveedor, para poder clasificarlo mejor. Cualquier dato que provenga únicamente del OCR se trata como no verificado y pasa siempre por validación posterior.
En Chile, la factura electrónica es obligatoria para prácticamente todos los contribuyentes de primera categoría desde el 1 de febrero de 2018, cuando terminó el proceso gradual que estableció la Ley 20.727 (con excepciones, por ejemplo para quienes operan sin cobertura de datos ni electricidad; fuente: SII). El DTE se emite en XML con esquema publicado por el SII: el dato trae estructura, tipos y totales definidos, y hay menos que adivinar. Aun así, conviene verificar la versión de esquema y no asumir que todo proveedor entrega XML válido. Si el cliente usa el sistema de facturación gratuito del SII (Portal MIPYME), puede generar un archivo de respaldo en XML de los DTE recibidos, filtrando por RUT, folio, fechas y tipo de documento (guía del SII); esa función cubre solo lo recibido a través de ese portal, y con otros sistemas el XML llega por el intercambio entre contribuyentes. Un caso que implementé: un bot de Playwright contra el servicio en línea del SII para traer la información a nivel de totales —base, IVA y total— desde el propio registro. El detalle de líneas se reconstruye aparte y se marca como dato reconstruido, no leído. Este tipo de integración depende de la disponibilidad y las condiciones de uso del servicio: conviene prever una ruta alternativa.
Clasificar sin adivinar y validar antes de postear
Con el dato duro resuelto queda la clasificación, que muchos intentan resolver con un prompt gigante. El agente puede investigar en la web a qué se dedica el proveedor y cruzar ese giro con el de la empresa que contabiliza, más los parámetros entregados por cliente. La clasificación no queda a juicio del modelo: se mueve dentro de un conjunto acotado de cuentas válidas para esa empresa, con reglas explícitas de precedencia. La búsqueda web es apoyo, no fuente de verdad: si el giro no se determina con razonable confianza, el caso se deriva a revisión.
Además, una factura no dice por sí sola dónde va: según lo que se compró, puede terminar en costo, gasto, activo fijo, intangible u otro activo y, en casos especiales, en un pasivo (por ejemplo, la cuota de un leasing). Por eso la contabilizo en dos tiempos: primero la factura entra a una cuenta puente de gastos por asignar mientras el agente analiza al proveedor (OCR más búsqueda en internet de su giro); después, en un segundo comprobante, imputo la cuenta definitiva y la cuenta puente queda en cero.
El modelo propone; el código verifica. Nada se postea sin pasar por estas comprobaciones:
| Validación | Qué comprueba | Tipo |
|---|---|---|
| Cuadre aritmético | Suma de líneas = base; base + IVA = total | Determinista |
| Dígito verificador del RUT | Módulo 11 sobre el RUT del emisor | Determinista |
| Duplicados | Tipo de documento + folio + RUT emisor + fecha + monto ya registrado | Determinista |
| Cuadre debe = haber | Suma de cargos igual a suma de abonos | Determinista |
| Coherencia de cuenta | La cuenta definitiva propuesta pertenece al catálogo válido del cliente | Determinista |
| Saldo de la cuenta puente | Cada reclasificación deja en cero lo asignado; el saldo pendiente se informa | Determinista |
Si alguna falla, el documento no se postea: se deriva a revisión con el motivo exacto.
Consistencia determinista: la misma cuenta, siempre
Para un mismo proveedor X que entrega un producto o servicio a una empresa H, la cuenta debería ser siempre la misma: sin importar el monto, la fecha, el orden de llegada ni cuántas veces se reprocese el documento. Esa reproducibilidad es más auditable que el acierto factura a factura: un contador puede discutir si un gasto va a una cuenta u otra, pero difícilmente aceptará que la misma operación caiga en dos cuentas distintas según el día.
En la práctica contable hay quien contabiliza y quien revisa; copio ese patrón con un agente auditor en dos capas: reglas fijas (un archivo versionado con las indicaciones contables de cada empresa) e histórico del ERP (consistencia estadística por proveedor y tipo de operación). El histórico puede traer errores de periodos cerrados que no se corrigen: el auditor no los arregla, los detecta, los reporta y de esos desvíos salen nuevas instrucciones.
Aunque el agente proponga el asiento, alguien debe revisarlo y firmarlo, y cada asiento debería guardar su traza —fuente del dato, ruta de clasificación, validaciones ejecutadas, resultado del auditor— asociada a quien lo aprobó. La trazabilidad y el control interno siguen siendo humanos; marcos como COSO apuntan en esa dirección.
Hay que medir el acierto real, no el percibido: proporción contabilizada por ruta determinista, derivaciones a revisión humana (si son 0%, conviene sospechar), errores que se escapan después de la aprobación humana y fragmentación de cuentas. Los límites siguen ahí: facturas no estándar, servicios mixtos, matices tributarios, giros mal descritos, periodos cerrados con errores heredados y cambios normativos o de esquema.
Ejemplo en dos comprobantes
Factura de Papelería Andina SpA por insumos de oficina. Base 100.000, IVA 19%, total 119.000. Los códigos de cuenta son ilustrativos.
Comprobante 1 — contabilización de la factura
| Cuenta | Descripción | Debe | Haber |
|---|---|---|---|
| 4205-99 | Gastos por asignar (cuenta puente) | 100.000 | |
| 1110-02 | IVA crédito fiscal | 19.000 | |
| 2101-01 | Proveedores nacionales — Papelería Andina SpA | 119.000 | |
| Totales | 119.000 | 119.000 | |
Comprobante 2 — imputación definitiva, después del análisis del proveedor
| Cuenta | Descripción | Debe | Haber |
|---|---|---|---|
| 4205-01 | Gasto en útiles de oficina | 100.000 | |
| 4205-99 | Gastos por asignar (cuenta puente) | 100.000 | |
| Totales | 100.000 | 100.000 | |
Verificación: ambos comprobantes cuadran (119.000 = 119.000 y 100.000 = 100.000), el IVA se calculó sobre la base (100.000 × 0,19 = 19.000) y la cuenta puente queda en cero (100.000 − 100.000). Si el análisis concluyera que lo comprado es un activo fijo, el segundo comprobante debitaría la cuenta de activo fijo que corresponda en lugar del gasto; si fuera la cuota de un leasing, iría a la cuenta de pasivo correspondiente. La procedencia del crédito fiscal depende de que el IVA esté correctamente separado en el documento de origen y de que se cumplan los requisitos normativos aplicables; con prorrateos o exenciones, esa evaluación no se automatiza sin una regla explícita.
Preguntas frecuentes
¿Puedo dejar de revisar las facturas si el agente tiene 99% de acierto?
No de forma responsable. Un 1% de error sobre 5.000 facturas mensuales son 50 asientos potencialmente malos: la revisión humana se concentra, no desaparece.
¿Qué pasa si no hay dato estructurado para validar el total?
El documento no se contabiliza solo: va a revisión humana. El OCR puede apoyar la lectura, pero no decide por sí mismo, y el sistema nunca completa un número que no pudo verificar: esa es la regla dura del diseño.
¿Sirve un solo prompt para todas mis empresas?
No. Las indicaciones contables se personalizan por cliente; un prompt universal tiende a producir clasificaciones inconsistentes entre sociedades.
¿Cómo evito que el agente invente una cuenta que no existe?
Restringiendo el catálogo: el agente solo puede proponer cuentas del plan contable cargado para esa empresa, y cualquier otra salida es inválida por definición.
El cierre honesto
“Sin error” no significa cero ediciones manuales: eso hoy es irreal como promesa. Significa cero errores materiales, cero invención de cifras y la misma cuenta para el mismo proveedor, producto y empresa, siempre. Es una meta que se puede diseñar, medir y auditar, con límites claros y revisión humana donde corresponde; Chile es solo el caso de ejemplo y el mapeo normativo no se reutiliza entre países.
Si estás evaluando implementar un agente de IA para contabilizar facturas de compras, parte por el flujo real: qué fuentes de dato existen hoy, qué validaciones deterministas faltan y qué KPIs exigirle a un proveedor antes de firmar. Puedes contarme tu caso escribiendo a contacto@aicorebusiness.com (o desde la página de contacto): si me cuentas el formato de tus facturas y el origen del dato (XML, portal o PDF), reviso si tu flujo admite una ruta determinista.
Este artículo tiene fines informativos y educativos y no constituye asesoría tributaria, contable ni legal. Las cifras, cuentas y asientos mostrados son ejemplos ilustrativos y pueden no coincidir con el plan contable, la normativa ni la situación particular de tu empresa. Antes de implementar cualquier automatización contable o de decidir sobre IVA, crédito fiscal, DTE o Registro de Compras, consulta con un contador auditor o asesor tributario calificado y verifica la normativa vigente en tu jurisdicción.