El agente de facturas duplicadas de Village Roadshow en SAP: revisa todas las facturas antes del pago y decide el equipo

En dos frases

Village Roadshow, el grupo australiano de Village Cinemas y de los parques temáticos de la Gold Coast, tiene un agente llamado DIANA que revisa todas las facturas de proveedor de sus cuentas a pagar en SAP en busca de duplicados antes del pago, y es el equipo de cuentas a pagar quien decide si cada una se bloquea o se libera. Es de los pocos agentes de finanzas en producción en una empresa identificada con población, gasto y modelo de gobierno publicados, pero casi todas las cifras vienen del proveedor que lo construyó o del resumen de una ponencia, y el titular del «99,4 % de acierto» no se define en ningún sitio.

Quién lo hace y por qué interesa

Village Roadshow explota cines, parques como Warner Bros. Movie World y Sea World y una distribuidora de cine, con SAP como columna vertebral de sus procesos financieros. El 26 de agosto de 2026 anunció en LinkedIn que su «primer compañero digital» ya funcionaba: DIANA, siglas en inglés de agente de análisis y aviso de facturas duplicadas. La publicación reparte bien los papeles: DIANA analiza los datos de las facturas, señala posibles duplicados y avisa a quien corresponde; «cada factura señalada la revisa una persona», cada recomendación lleva sus pruebas y los resultados se siguen en informes auditables. Agradece el trabajo a los equipos de finanzas y tecnología y a Business Core Solutions (BCS), socio de SAP.

Rajan Rana, responsable de habilitación y transformación con IA de Village Roadshow, presentará el caso en Mastering SAP Collaborate, la parada del SAP TechEd on Tour en Sídney, el 18 de noviembre de 2026. El proyecto es uno de los tres finalistas del premio Innovation Vanguard – Customer of the Year de SAPinsider APAC 2026, junto a Mitre10 New Zealand y Suntory Oceania.

Tres motivos para mirarlo de cerca:

• Es un control clásico, no un chatbot. El pago duplicado es un riesgo de manual en cuentas a pagar, y aquí se trata de pasar de revisar una muestra a revisar toda la población antes de que salga el dinero.
• El gobierno tiene nombre. El resumen habla de «derechos de decisión humanos», de un «Agent Boss», un «Agent Coach» y un mandato de dirección. Pocos casos publicados dicen quién responde de un agente después del arranque.
• Los vínculos comerciales están a la vista y se pueden ponderar. BCS construyó DIANA; su empresa hermana ProxyN la lanzó como producto el 15 de octubre de 2026; BCS es patrocinador Gold del congreso de Sídney. El consejero delegado fundador de ProxyN es Arul Arogyanathan, el mismo nombre que el CIO de Village Roadshow citado en un caso de Lemongrass de 2024 sobre la migración de SAP del grupo a AWS. No sabemos qué cargo tenía durante el proyecto; lo mencionamos para que cada lector valore las fuentes.

Herramientas y arquitectura

Lo que se sabe y quién lo dice:

• ERP. El «entorno SAP productivo» de Village Roadshow (publicación de la empresa). Un ingeniero de BCS dice que DIANA «vigila todo el libro de cuentas a pagar de SAP». El caso de Lemongrass de 2024 describe un entorno SAP (ERP, CRM, Fiori, GRC, BW y otros) trasladado a AWS tal cual; ninguna fuente sobre DIANA dice qué versión de SAP usa.
• Plataforma. DIANA está «hecha sobre BCS Symphony», según ese ingeniero. La web de Symphony describe una capa de orquestación en la que el modelo de lenguaje solo interpreta y propone, mientras la plataforma valida y ejecuta con API estándar, respeta las autorizaciones de SAP, registra cada acción y escala cuando la confianza es baja. Dice que el cliente puede usar su propio modelo aprobado. Ninguna fuente nombra el modelo de DIANA.
• Equipo. Consultores funcionales de SAP, desarrolladores ABAP, constructores de Symphony y probadores, según la misma publicación: hubo desarrollo en SAP aunque Symphony anuncie «cero modificaciones del núcleo».
• Datos de entrenamiento. ProxyN dice que DIANA se entrenó con doce meses del histórico de cuentas a pagar del grupo en SAP.
• Límites de decisión (descripción genérica del proveedor). DIANA puntúa cada factura, ordena candidatas, reúne pruebas y avisa al responsable; recomienda bloquear o liberar; escala las coincidencias dudosas a revisión de cuentas a pagar, las anomalías del maestro de proveedores a su responsable, los patrones de posible fraude a control e investigaciones y los pagos grandes inminentes a quien los aprueba. «Depende» del controller financiero.

Un matiz: la ficha de ProxyN incluye entre las tareas de DIANA «bloquea o aparca con pruebas» y «contabiliza cuando se libera», mientras que Village Roadshow solo habla de señalar y avisar. No consta si en Village Roadshow DIANA pone ella misma el bloqueo de pago.

Paso a paso para replicar el patrón

No hace falta Symphony para copiar el diseño. Estos pasos sirven en SAP y en casi cualquier ERP; las referencias a SAP están porque es el caso.

1. Pon nombre al control y a sus personas. Una línea: «Ninguna factura de proveedor se paga dos veces». El controller financiero responde del control, el equipo de cuentas a pagar decide, una persona es la «dueña del agente» (responde de los resultados) y otra la «entrenadora» (revisa los cambios de reglas). Son los papeles de Agent Boss y Agent Coach de Village Roadshow; las definiciones son nuestras.
2. Entiende qué comprueba ya SAP. El control estándar de duplicados (el indicador «verificar factura doble» del maestro de proveedores para las contabilizaciones de FI, el mensaje F5 117, que se puede convertir en error en OBA5, y un ajuste propio en la verificación de facturas logística) compara valores exactos en pocos campos, como proveedor, referencia, fecha del documento y, según el caso, moneda e importe. Una referencia tecleada «FRA-0012» una vez y «FRA0012» la siguiente pasa el filtro.
3. Crea una línea base con el histórico. Extrae doce meses de facturas: proveedor, NIF y datos bancarios, sociedad, referencia, fechas de documento y de contabilización, importe bruto, moneda, canal de entrada (EDI, PDF por correo, portal, manual), pedido y entrada de mercancía, y estado de pago. Revisa el periodo para etiquetar los duplicados confirmados (también los ya recuperados). Así tendrás la tasa de duplicados, el importe en juego y un conjunto de prueba.
4. Genera parejas candidatas, no veredictos. Normaliza referencias (mayúsculas, espacios, guiones, ceros a la izquierda, prefijos), convierte monedas y empareja facturas del mismo proveedor, o de fichas distintas con el mismo NIF o cuenta bancaria, con importes dentro de una tolerancia y fechas dentro de una ventana. Incluye las demás sociedades: el duplicado suele llegar a otra empresa del grupo.
5. Puntúa y explica. Primero reglas deterministas; un modelo solo donde importe el texto (descripciones de líneas, contenido del PDF). Cada alerta lleva la comparación: las dos facturas juntas, los campos que coinciden, las diferencias y el motivo de la puntuación.
6. Colócalo antes de la propuesta de pagos. En SAP, revisar las partidas abiertas antes del programa de pagos automáticos (F110) con un corte claro. Empieza solo avisando. Cuando la precisión sea aceptable, deja que el agente ponga un bloqueo de pago reversible, y nada más: ni contabilizar, ni compensar, ni anular.
7. Funciona en paralelo y mide. Compara el agente con el control actual al menos durante un ciclo completo de pagos. Mide la precisión (alertas que son duplicados reales), la exhaustividad (duplicados conocidos que encuentra), el importe frenado y el tiempo hasta la decisión.
8. Gobierna el aprendizaje. Realimenta solo decisiones validadas, versiona cada cambio de regla o umbral y que lo apruebe la persona entrenadora. Envía a auditoría interna un informe mensual del control: población revisada, alertas, decisiones y excepciones.

Una hoja de puntuación para empezar (nuestra, no la de DIANA)

Señal	Puntos
Mismo proveedor y misma referencia normalizada	40
Fichas de proveedor distintas con el mismo NIF o cuenta bancaria	30
Mismo importe bruto (tras convertir moneda)	25
Importe a ±1 % o con un tipo de IVA de diferencia	10
Fechas de documento a 10 días o menos	10
Mismo pedido y entrada ya facturados por completo	25
Canales de entrada distintos (p. ej., EDI y PDF por correo)	5
Abono o anulación entre las dos	−40

Revisa todo lo que llegue a 70 puntos antes de la propuesta de pagos y mira cada semana unas cuantas por debajo para saber qué se escapa. Ajusta los pesos con tu histórico etiquetado, no a ojo.

Un ejemplo concreto (cifras hipotéticas)

Las 132.000 facturas anuales que se atribuyen a Village Roadshow son unas 11.000 al mes. Imagina un grupo de ese tamaño con estas cifras inventadas:

• La factura «FRA-0012» de un proveedor, por 18.450,00 A$, llega por EDI el 3 de marzo y se contabiliza. El 7 de marzo la misma factura llega en PDF por correo a otra división y se teclea como «FRA0012». El control exacto de SAP ve dos referencias distintas. La hoja da 40 + 25 + 10 + 5 = 80 puntos y la pareja va a la cola con los dos documentos juntos. La persona de cuentas a pagar bloquea la segunda.
• Otra pareja suma 70: dos fichas de proveedor con la misma cuenta bancaria (30), mismo importe (25), fechas a una semana (10) y canales distintos (5). Se libera (es una segunda entrega real), pero el caso se escala a quien gestiona el maestro de proveedores, que fusiona la ficha duplicada. Es la corrección en origen de la que habla ProxyN.
• En el mes salen 160 parejas; 24 son duplicados confirmados por 190.000 A$ y 136 se liberan. La precisión es del 15 %. Si la revisión retrospectiva indica unos 30 duplicados, la exhaustividad ronda el 80 %.

Ese último punto es la conversación que hay que tener con cualquier proveedor: con 11.000 facturas y 30 duplicados, un sistema que no señala nada acierta el 99,7 %.

Resultados declarados

Afirmación	Cifra	Quién lo dice
Facturas revisadas al año	~132.000 (132.159 en la web de ProxyN)	Resumen de la sesión; ProxyN
Gasto anual cubierto	425 M A$, cuatro divisiones, ocho monedas	Resumen de la sesión; ProxyN
Acierto de detección	99,4 %	Resumen de la sesión; página del evento de ProxyN
Plazo hasta producción	~8 semanas / 12 desde el primer taller	Resumen / caso de cliente de ProxyN
Esfuerzo de revisión manual	−60 a 70 %	Biografía del ponente en la web del evento
Cola de revisión, primeros cuatro días	−92 %	Ingeniero de BCS en LinkedIn
ROI a tres años	440 %	Biografía del ponente en la web del evento

La publicación de Village Roadshow no da cifras. La portada de ProxyN añade una cita anónima de un «Group AP/AR Manager» de «un destacado grupo de ocio australiano» que llama a DIANA el miembro más fiable del equipo. Ninguna fuente publica cuántos duplicados se han encontrado, el importe frenado, la tasa de falsos positivos, cómo se calcula el ROI ni cuánto cuesta DIANA.

Limitaciones y riesgos

• Pruebas muy del proveedor. La empresa confirma el proyecto y la revisión humana; las cifras vienen del constructor, de su empresa hermana o del resumen de una ponencia en un congreso que patrocina.
• Cifras que no cuadran. Ocho semanas o doce; entre un 60 y un 70 % menos de esfuerzo o una cola un 92 % menor. Puede que midan cosas distintas (construcción frente a proyecto completo, régimen normal frente a primeros días), pero nadie lo aclara.
• El «acierto» no está definido. Sin precisión y exhaustividad sobre una tasa de duplicados conocida, un 99,4 % dice poco, como muestra el ejemplo.
• «Autónomo» frente a «deciden las personas». La biografía del ponente llama autónomo a DIANA; la empresa dice que una persona revisa cada alerta. Las dos cosas pueden ser ciertas (funciona sola, no decide nada), pero lee bien los límites antes de copiarlos.
• El aprendizaje puede desviarse. Si cada factura liberada enseña al agente que un patrón es correcto, quien consiga colar una puede enseñarle más. Solo debe aprender de decisiones validadas y con control de cambios.
• Fatiga de alertas. Una cola con un 85 % de falsos positivos acostumbra a pulsar «liberar». Vigila los tiempos de liberación y revisa una muestra.
• Lo que no se sabe. Versión de SAP, modelo, alojamiento, tratamiento de datos y precio no se publican. La sesión del 18 de noviembre puede aportar detalles; actualizaremos la entrada si es así.

Errores comunes

• Fiarse del control exacto del ERP y dar el riesgo por cubierto.
• Revisar después de la propuesta de pagos, cuando ya toca recuperar en vez de evitar.
• Olvidar las fichas de proveedor duplicadas, la causa más habitual según ProxyN.
• Dejar fuera abonos, anulaciones y facturas reemitidas, que parecen duplicados y saturan la cola.
• Revisar sociedad por sociedad cuando el duplicado cae en otra empresa del grupo o en otra moneda.
• Permitir que el agente contabilice o compense algo en los primeros meses.
• Presentar el «acierto» a la comisión de auditoría en vez de precisión, exhaustividad e importe frenado.

Conclusiones

DIANA es una buena referencia porque es aburrida en el buen sentido: un control, una población, un responsable claro, pruebas en cada alerta y personas que deciden. El diseño se copia con facilidad en SAP o en cualquier ERP con buenos datos de cuentas a pagar, y se puede empezar con reglas y una hoja de cálculo antes de comprar una plataforma de agentes. Lo que no conviene copiar es la forma de contar los resultados: pide la tasa de duplicados, la precisión, la exhaustividad y el importe frenado antes de creerte cualquier porcentaje de acierto, también este.