Empezar en modo lectura
Nuestra propuesta para una primera fase es trabajar con exportaciones o consultas autorizadas, sin modificar el sistema de origen. Conserva una instantánea identificada y un diccionario de campos. Así puedes reconstruir qué información se utilizó para cada informe.
No entregues a un modelo la responsabilidad de inventar categorías o completar importes ausentes. Los campos desconocidos deben quedar visibles como incidencias; un informe fluido puede ocultar un dato que todavía no existe.
Separar cálculos y explicación
Realiza agregaciones y reconciliaciones mediante reglas explícitas. Utiliza IA para preparar una explicación a partir de resultados comprobados, indicando periodo, unidad, fuente y restricciones. Si cambia una cifra, vuelve a generar o revisar la narración asociada.
Como criterio de aceptación de ejemplo, los totales de un conjunto cerrado deberían coincidir con la fuente y cada discrepancia debería tener un identificador. Esto es una exigencia de un piloto concreto, no una afirmación de exactitud universal de los modelos.
Un flujo útil para el equipo
El recorrido recomendado es recoger, normalizar, comprobar, preparar borrador, revisar y publicar. Las excepciones entran en una bandeja con responsable y motivo. Una corrección debe preservar el dato original y la decisión tomada.
No escribas automáticamente en contabilidad durante la primera fase. Una integración de escritura requiere permisos, reglas de aprobación, idempotencia y pruebas de reversión propias. Preparar un asiento y registrarlo son acciones con responsabilidades distintas.
Medir valor sin ocultar revisión
Compara el tiempo de preparación y revisión conjunta con la situación anterior. Registra incidencias detectadas, documentos faltantes y correcciones tras publicar. Una automatización que produce más borradores pero más errores puede empeorar la operación.
La ampliación se decide con responsables del proceso y evidencia del piloto. El diseño aquí descrito es orientativo, no acredita una implementación de cliente ni sustituye normas contables, juicio profesional o validación del auditor.
Ejemplo numérico: el informe que parece correcto pero duplica una operación
Ejemplo didáctico con datos sintéticos. Una exportación contiene dos ingresos de 1.250 y 750 euros y un ajuste de −200 euros. El total de control es 1.800 euros. Por un error de exportación aparece otra vez la operación de 750 euros con el mismo identificador. Sumar todas las filas produciría 2.550 euros.
Un modelo podría redactar una explicación convincente para ambos resultados. La corrección no depende del estilo del texto: depende de identificar la duplicidad y reconciliar el conjunto aceptado con el origen. El archivo de ejemplo conserva la fila repetida para que la incidencia se pueda revisar.
No recomendamos eliminar registros porque sus descripciones se parecen. Un mismo importe puede corresponder a dos operaciones legítimas. En este ejemplo existe un identificador repetido inequívoco; en un sistema real debe documentarse qué claves constituyen la identidad de la operación.
| ID | Concepto | Importe | Control |
|---|---|---|---|
| R001 | Ingreso A | 1.250 € | Único |
| R002 | Ingreso B | 750 € | Único |
| R003 | Ajuste | −200 € | Único |
| R002 | Ingreso B repetido | 750 € | Incidencia: ID duplicado |
| CONTROL | Conjunto aceptado | 1.800 € | Coincide con total de origen |
Capas del flujo y qué permite cada una
La instantánea conserva el archivo recibido y su identificador. La normalización convierte campos al esquema acordado sin cambiar su significado. Los controles verifican tipos, duplicados, periodos y totales. Solo entonces se prepara una tabla de resultados autorizada para redactar el comentario.
Cada capa debe producir un estado y un responsable. Si el total no concilia, el flujo puede preparar una incidencia, pero no etiquetar el informe como validado. La aprobación humana autoriza una versión concreta del documento; un cambio posterior de datos exige nueva revisión.
Contrato de datos antes de integrar
El contrato define moneda, periodo, convención de signo, zona horaria de las fechas, tratamiento de nulos y claves de unicidad. Diferenciar cantidad desconocida de cero evita que una normalización aparentemente inocente cambie el sentido económico del registro.
Cuando se conecta una API, el resultado debe conservar su periodo consultado, paginación y condición de completitud. Una respuesta HTTP correcta no prueba que se hayan obtenido todos los registros. Si se usa una exportación manual, debe existir un procedimiento para confirmar que corresponde al corte solicitado.
Un ajuste de redondeo solo es aceptable si tiene una regla aprobada y evidencia suficiente. No debe convertirse en una tolerancia general que absorba errores. El recurso de control propone campos para documentar cada diferencia y su resolución, sin fijar una política contable universal.
La narración no puede inventar causas
El modelo puede explicar que un indicador aumentó respecto del periodo anterior si el cálculo se le entrega comprobado. No puede afirmar que el aumento proviene de una campaña o un contrato si la entrada no contiene evidencia de esa causa. Distingue observación, explicación respaldada e hipótesis.
En el ejemplo, «el total aceptado es 1.800 euros tras resolver un registro duplicado» tiene soporte en los datos de control. «La actividad comercial mejoró» no lo tiene: falta una comparación y una definición de actividad. Una interfaz útil permite abrir la tabla que respalda cada conclusión.
Aceptación, supervisión y límites
Prueba exportaciones vacías, paginación incompleta, cambios de moneda, fechas fuera de periodo y duplicados legítimos frente a ilegítimos. Verifica que un error detenga la publicación o aparezca como pendiente, según el contrato acordado. Registra el tiempo total de preparación y revisión, no solo el tiempo de generación del comentario.
Antes de incorporar escritura contable, hace falta un proyecto de control adicional. Incluye identidad autorizada, aprobación vinculada al asiento, comprobación de efectos e idempotencia. Esta guía se limita a preparación y reporting: no acredita adecuación contable ni sustituye juicio profesional.
El dataset descargable facilita una demostración reproducible de conciliación aritmética. No prueba robustez en producción, compatibilidad con un software contable ni integridad de datos reales. Esas afirmaciones exigen pruebas adicionales sobre el entorno concreto.
Recursos para trabajar esta guía
Descargas abiertas. Adapta los criterios a tu proceso; los conjuntos de ejemplo contienen datos sintéticos.
Dataset sintético de conciliación financiera
Cuatro filas, un ID duplicado y un total de control; permite comprobar la aritmética del ejemplo.
Descargar JSON ↓Registro de controles y excepciones de reporting
Plantilla para corte, integridad, conciliación, incidencias y aprobación de una versión.
Descargar Markdown ↓Fuentes y alcance
Consulta de referencias: 8 OCT 2026. Los ejemplos y criterios operativos son propuestas editoriales de Asgardium; no demuestran resultados de clientes.
Marco voluntario de gestión de riesgos. Los pasos operativos propuestos en esta guía son criterio editorial de Asgardium.
Continúa por este tema
ASGARDIUM CONSULTING