Preparación de los datos financieros para la IA: catálogo de cuentas, ERP y datos maestros

Por Jane Ha · Actualizado el 11 de octubre de 2026

La preparación de los datos financieros es el grado en que su catálogo de cuentas, las transacciones del ERP y los datos maestros (proveedores, clientes, artículos) son lo bastante exactos, consistentes y conectados para que un sistema de IA los lea y llegue a la misma respuesta que un contralor (controller) cuidadoso. Un modelo no puede saber que «Acme Corp», «ACME Corporation» y «Acme Corp.» son un mismo proveedor, ni que tres centros de costos significan lo mismo bajo códigos distintos. Los trata como entidades separadas, y todo pronóstico, conciliación y explicación de variaciones que se construya encima hereda esa división.

Esta guía está dirigida a CFOs, contralores, directores de finanzas y gerentes de finanzas que están a punto de hacer un piloto de IA para el cierre, las cuentas por pagar, la cobranza, los pronósticos o los reportes, y quieren saber qué debe ser cierto primero acerca de los datos. Se ubica en la capa de datos (Level 0) del ACE Framework, donde Ingest y Analyze ocurren antes de que se prediga o genere cualquier cosa. Para la visión de toda la función, comience con la IA en finanzas, y para los flujos de trabajo concretos, consulte los casos de uso de IA en finanzas.

Datos clave

• En el estudio de RGP de diciembre de 2025 con 200 CFOs de EE. UU., el 35% señaló la confianza en los datos como su principal obstáculo para obtener ROI de la IA, y solo el 10% dijo confiar plenamente en los datos de su empresa (encuesta de RGP a CFOs).
• En el mismo estudio, el 86% de los CFOs dijo que los sistemas heredados limitan su preparación para la IA (encuesta de RGP a CFOs).
• En un estudio de Harvard Business Review con 75 ejecutivos que revisaron cada uno los registros de datos creados recientemente en sus propios departamentos, el 47% de los registros nuevos tenía al menos un error crítico, y solo el 3% de las puntuaciones de calidad de datos podía calificarse como aceptable con el estándar más laxo (Nagle, Redman y Sammon, HBR, 2017). Son datos generales de negocio y un estudio más antiguo, no una referencia exclusiva de finanzas, pero la lección sobre los registros recién creados se aplica a todos los formularios de datos maestros.

Por qué la IA en finanzas depende por completo de los datos

Todos los casos de uso de IA en finanzas leen de los mismos pocos lugares. Una herramienta de conciliación de facturas lee los registros de proveedores y las órdenes de compra. Un pronóstico de caja lee las cuentas por cobrar, las cuentas por pagar y los datos bancarios. Una herramienta de comentarios de variaciones lee el libro mayor y le dice por qué se movió una cifra. Un asistente de cierre lee las balanzas de comprobación y los asientos contables, y luego señala lo que parece raro.

Así que la primera pregunta no es «¿es bueno el modelo?». Es «¿qué está mirando?». Tres cosas salen mal cuando la respuesta es «un desorden»:

• Los modelos aprenden sus inconsistencias como si fueran patrones. Si un mismo gasto cae en cuatro cuentas según quién lo codificó, un modelo de clasificación aprende cuatro hábitos y los trata como igualmente válidos.
• Los asistentes explican cifras que están mal. Un modelo de lenguaje que redacta comentarios de variaciones describirá con fluidez una oscilación de ingresos, aunque esa oscilación sea un error de mapeo. Es el problema de la alucinación en un contexto financiero: fluida, segura y sin respaldo en los libros.
• Los reportes no coinciden. Cuando el ERP, la herramienta de planeación y la capa de BI definen «región» o «cliente» de manera distinta, el primer reporte generado por IA se convierte en un debate sobre definiciones en lugar de una decisión.

El trabajo rinde frutos con IA o sin ella: cierres más rápidos, auditorías más limpias y menos reclasificaciones provienen de las mismas mejoras.

Las tres capas de los datos financieros

Piense en los datos financieros como tres capas. La IA depende de las tres, y un defecto en una capa inferior aparece en todas las capas superiores.

La mayoría de los equipos empieza por las transacciones porque ahí el dolor es visible. Pero si el catálogo y los datos maestros no son confiables, limpiar las transacciones solo trata los síntomas.

Catálogo de cuentas: el idioma que lee su IA

El catálogo de cuentas es el vocabulario de las finanzas. Toda función de IA que clasifica, pronostica o explica está traduciendo a través de él. Cuatro problemas de diseño causan la mayor parte de las dificultades.

Proliferación de cuentas. Los catálogos que crecieron mediante adquisiciones suelen tener miles de cuentas, muchas inactivas y muchas casi duplicadas («Viajes», «Viajes - Nacionales», «T&E Varios»). Un modelo de clasificación tiene que elegir entre ellas, y la respuesta honesta es que las personas también eligen de forma inconsistente.

Significado colado en los números de cuenta. Cuando una empresa necesita ver el gasto por departamento o región y su sistema no puede, crea cuentas como «Marketing - EMEA - Eventos». Eso funciona hasta que hay ocho regiones, diez departamentos y una reorganización. El mejor diseño mantiene las cuentas para la naturaleza de la partida y coloca el departamento, la región, el producto y el proyecto en dimensiones separadas (centro de costos, segmento, etiqueta). Los modelos manejan mucho mejor un conjunto pequeño de cuentas limpias más dimensiones que una lista plana gigante.

Diferencias entre entidades y normas contables locales. Las subsidiarias con sus propios catálogos locales, mapeados a un catálogo del grupo mediante una hoja de cálculo, son una fuente común de errores silenciosos. Si el mapeo vive en el libro de trabajo de alguien, una herramienta de IA que lee datos del grupo no puede saber cuándo cambió.

Uso sin documentar. Una cuenta llamada «Otros» o «Transitoria» sin un propósito por escrito se convierte en un basurero. Los modelos no pueden distinguir un «otros» genuino de una partida sin resolver.

El estándar práctico es sencillo de enunciar: cada cuenta tiene una definición documentada, un responsable, una regla de cuándo usarla y cuándo no, y un mapeo a las líneas de reporte externas. Donde eso existe, incluso la automatización básica funciona mejor, y un asistente basado en recuperación puede citar las definiciones a los usuarios, como se describe en la generación aumentada por recuperación.

Calidad de los datos del ERP: de dónde vienen los defectos

Su ERP no es solo una fuente de datos. Es donde se crean los defectos, por formularios que permiten texto libre, campos opcionales, anulaciones manuales y soluciones provisionales. Cinco patrones aparecen una y otra vez.

El hallazgo de RGP de que el 86% de los CFOs afirma que los sistemas heredados limitan la preparación para la IA encaja con este panorama (RGP). Los ERP heredados no son inutilizables, pero tienden a tener los controles más laxos sobre cómo se crean los registros, y los registros más antiguos.

No tiene que reemplazar el ERP para avanzar. Muchos equipos llegan lejos agregando validación al crear los registros y concentrando la limpieza en los pocos campos que lee un caso de uso determinado.

Datos maestros: proveedores, clientes y artículos

Los datos maestros son el conjunto de registros a los que apuntan las transacciones. Si están mal, toda transacción que los referencia también está mal, de maneras que un modelo no puede ver.

Proveedores. El maestro de proveedores impulsa la automatización de cuentas por pagar, el análisis del gasto y los controles de fraude. Los defectos típicos son duplicados, identificadores fiscales ausentes, varias cuentas bancarias por proveedor sin pista de aprobación, y relaciones matriz-filial que no están registradas (por lo que no se ve que se le está comprando a un mismo grupo a través de cuatro entidades). Una herramienta de IA que concilia facturas con órdenes de compra funcionará bien con una lista de proveedores limpia y mal con una lista en la que el mismo proveedor aparece bajo variantes.

Clientes. El maestro de clientes impulsa la cobranza, el riesgo crediticio, el análisis de ingresos y el pronóstico de caja. Esté atento a cuentas duplicadas, confusión entre facturar a y enviar a, jerarquías ausentes (de modo que la exposición del grupo es invisible) y condiciones de pago que difieren entre el CRM y el ERP. Un modelo de cobranza que predice pagos tardíos necesita una identidad de cliente consistente a lo largo de años de historial.

Artículos y productos. Los datos maestros de artículos o SKU importan más cuando el inventario, la contabilidad de costos o los ingresos por producto están dentro del alcance. Las unidades de medida inconsistentes, los SKU duplicados y los campos de costo o categoría faltantes rompen la valuación de inventarios, el análisis de márgenes y los pronósticos de demanda.

Reglas comunes para los tres. Asigne a cada registro un identificador persistente que nunca se reutilice. Estandarice los nombres y las direcciones a un formato documentado. Registre quién creó o cambió un registro y cuándo. Mantenga un estado inactivo en lugar de eliminar registros que tienen historial. Y decida quién aprueba los nuevos proveedores, clientes y artículos, porque el aprobador es el verdadero punto de control de la calidad de los datos.

Si planea trasladar estos datos a un almacén de datos o a un lakehouse para que los modelos puedan leerlos, el lado de la integración se trata en las canalizaciones de datos.

Una lista de verificación de preparación de datos para la IA en finanzas

Úsela antes de aprobar un piloto. Para cada fila, marque Listo, Parcial o No listo. Dos o más respuestas «No listo» en las filas de las que depende su caso de uso significan que primero se arreglan los datos y después se hace el piloto.

No todos los pilotos necesitan todas las filas. Una herramienta que redacta comentarios a partir de un conjunto aprobado de reportes de gestión necesita sobre todo las filas del catálogo y del mapeo. Una herramienta de cuentas por pagar depende del maestro de proveedores y de los controles de creación. Un pronóstico de caja necesita el maestro de clientes, el historial y la integración.

Una secuencia que funciona

No necesita un programa de datos de varios años antes de empezar. Una secuencia que mantiene el impulso:

1. Elija primero un caso de uso. Elíjalo con los criterios de la priorización de casos de uso de IA y luego enumere solo los campos y las tablas que necesita.
2. Perfile los datos de ese caso de uso. Cuente los duplicados, los vacíos y los valores inconsistentes solo en esos campos. Una página de cifras mueve a la dirección más rápido que una queja general sobre los datos. El método sencillo de HBR, en el que las personas revisan una muestra de registros recientes y cuentan cuántos están libres de errores, sirve para una primera pasada (HBR).
3. Corrija en el origen, no aguas abajo. Limpiar una copia en el almacén de datos mientras el ERP sigue produciendo registros defectuosos significa volver a limpiarla el próximo trimestre. Agregue validación a los formularios, haga obligatorios los campos y reemplace el texto libre con listas desplegables.
4. Corrija el proceso que crea los defectos. Los proveedores duplicados suelen venir de una solicitud de alta que omite el paso de búsqueda. La proliferación de cuentas viene de permitir que cualquiera solicite una cuenta nueva. Ponga una puerta de aprobación en esos puntos.
5. Documente las definiciones. Escriba qué significa cada cuenta, dimensión y campo clave de datos maestros. Esto también se convierte en el material de referencia del que puede nutrirse un asistente.
6. Asigne la custodia de los datos. Una persona de finanzas es responsable de cada conjunto de datos importante, con un reporte mensual de calidad para el equipo directivo de finanzas.
7. Haga el piloto con una verificación humana y luego amplíe. Ejecute el piloto sobre la porción limpia y mantenga a un revisor en el circuito, como se describe en human-in-the-loop. Amplíe cuando el primer caso de uso sea estable.

Si está considerando agentes que actúan, no solo que responden, por ejemplo contabilizar asientos o liberar pagos, la exigencia en datos y permisos es mayor. Eso se trata en los agentes de IA para finanzas.

Errores comunes

• Comprar primero la herramienta y descubrir los problemas de datos en el piloto. Los proveedores hacen demostraciones con datos de muestra ordenados. Su primera semana en producción no se parecerá a la demostración.
• Limpiar una sola vez. Sin un responsable de datos y una verificación recurrente, la calidad se deteriora en un año a medida que se acumulan nuevos proveedores, reorganizaciones y adquisiciones.
• Rediseñar el catálogo a mitad del piloto. Si la estructura cambia mientras un modelo aprende del historial, usted ha roto la comparación. Congélela o reexprese primero el historial.
• Confiar en los resultados de la IA sin vincularlos al libro mayor. Toda cifra que produzca una herramienta de IA debe conciliarse con el libro mayor o con un reporte fuente designado.
• Omitir la cuestión del acceso. Los datos financieros incluyen salarios, datos bancarios y resultados aún no anunciados, así que limite por rol lo que un asistente puede leer.
• Tratar los datos maestros como trabajo de TI. Quien aprueba un nuevo proveedor o cliente decide la calidad de los datos todos los días. Conviértalo en una responsabilidad de finanzas.