Village Roadshow's duplicate-invoice agent in SAP: every supplier invoice screened before payment, people decide

In two sentences

Village Roadshow, the Australian group behind Village Cinemas and the Gold Coast theme parks, has an agent called DIANA screening every supplier invoice in its SAP accounts payable for duplicates before payment, with the AP team making every block-or-release decision. It is one of the few finance agents in production at a named company with a population, a spend figure and a governance model attached, but almost every number comes from the vendor that built it or from a conference abstract, and the headline “99.4% accuracy” is never defined.

Who does it and why it is interesting

Village Roadshow runs cinemas, theme parks such as Warner Bros. Movie World and Sea World, and film distribution, with SAP as the backbone of its finance processes. On 26 August 2026 the company announced on LinkedIn that its “first digital co-worker” was live: DIANA, the Duplicate Invoice Analysis and Notification Agent. The post is careful about the division of labour: DIANA analyses invoice data, flags potential duplicates and notifies the right people; “every flagged invoice is reviewed by a person”, each recommendation carries supporting evidence and outcomes are tracked in auditable reporting. It thanks the finance and technology teams and Business Core Solutions (BCS), an SAP partner.

Rajan Rana, Village Roadshow’s Head of AI Enablement and Transformation, will present the case at Mastering SAP Collaborate, the SAP TechEd on Tour event in Sydney, on 18 November 2026. The project is one of three finalists for SAPinsider’s APAC 2026 Innovation Vanguard – Customer of the Year award, alongside Mitre10 New Zealand and Suntory Oceania.

Three things make it worth a close look:

• It is a classic control, not a chatbot. Duplicate payments are a textbook accounts payable risk, and the goal here is to move from checking a sample to checking the whole population before money leaves.
• The governance is named. The abstract talks about “human decision rights”, an “Agent Boss”, an “Agent Coach” and an executive mandate. Few published cases say who owns an agent after go-live.
• The commercial ties are visible, so you can weigh them. BCS built DIANA; its sister company ProxyN launched DIANA as a product on 15 October 2026; BCS is Gold Sponsor of the Sydney event. ProxyN’s founding CEO is Arul Arogyanathan, the same name as the Village Roadshow CIO quoted in a 2024 Lemongrass case study about the group’s SAP migration to AWS. We do not know his role at the time of the project; we mention it so readers can judge the sources.

Tools and architecture

What is known, and from whom:

• ERP. Village Roadshow’s “live SAP environment” (company post). A BCS engineer says DIANA “monitors the full SAP AP ledger”. The 2024 Lemongrass case study describes an SAP landscape (ERP, CRM, Fiori, GRC, BW and others) moved to AWS in a lift and shift; none of the DIANA sources say which SAP release it runs against.
• Platform. DIANA is “built on BCS Symphony”, according to that engineer. Symphony’s own site describes an orchestration layer in which the language model only interprets and proposes, while the platform validates and executes through standard APIs, enforces SAP authorisations, logs every action and escalates when confidence is low. It says customers can bring their own approved model. No source names the model DIANA uses.
• Build team. SAP functional consultants, ABAP developers, Symphony builders and testers, per the same post, so there was SAP-side development even though Symphony markets “zero core modifications”.
• Training data. ProxyN’s site says DIANA was trained on twelve months of the group’s own AP history in SAP.
• Decision boundary (vendor’s generic description). DIANA scores every invoice, ranks candidates, assembles evidence and notifies the owner; it recommends block or release; it escalates low-confidence matches to AP review, vendor-master anomalies to the master-data owner, patterns suggesting fraud to controls and investigations, and imminent high-value payments to the payment approver. It “reports to” the financial controller.

One nuance: ProxyN’s page lists “blocks or parks with evidence” and “posts when cleared” among DIANA’s tasks, while Village Roadshow’s post only mentions flagging and notifying. Whether DIANA sets a payment block itself at Village Roadshow is not stated.

Step by step to replicate the pattern

You do not need Symphony to copy the design. The steps below work for SAP and for most ERPs; the SAP references are there because that is the case.

1. Name the control and its people. Write one line: “No supplier invoice is paid twice.” Make the financial controller accountable, the AP team the decision-makers, one person the “agent owner” (who answers for results) and one the “coach” (who reviews rule changes). Those roles echo Village Roadshow’s Agent Boss and Agent Coach; the definitions are ours.
2. Understand what SAP already checks. SAP’s standard duplicate check (the “check double invoice” flag on the vendor master for FI postings, message F5 117 that can be raised to an error in OBA5, and a separate customising setting for logistics invoice verification) compares exact values on a short list of fields such as vendor, reference, document date and, depending on the case, currency and amount. A reference typed “INV-0012” once and “INV0012” the next time passes.
3. Build a baseline from history. Extract twelve months of vendor invoices: vendor, tax ID and bank details, company code, reference, document and posting dates, gross amount, currency, intake channel (EDI, email PDF, portal, manual), PO and goods receipt, and payment status. Run a retrospective review to label confirmed duplicates (including those already recovered). This gives you the duplicate rate, the value at stake and a test set.
4. Generate candidate pairs, not verdicts. Normalise references (case, spaces, dashes, leading zeros, prefixes), convert currencies, and pair invoices that share a vendor or a tax ID or bank account across vendor records, with amounts within a tolerance and dates within a window. Include other company codes; a duplicate often arrives at a second entity.
5. Score and explain. Use deterministic rules first, then a model only where text matters (line descriptions, PDF content). Every flag must carry a comparison record: both invoices side by side, the matching fields, the differences and the reason for the score.
6. Put it before the payment run. In SAP that means screening open items ahead of the automatic payment program (F110) with a clear cut-off. Start with notification only. Once precision is acceptable, allow the agent to set a reversible payment block, and only that: no posting, clearing or reversal.
7. Run in parallel and measure. Compare the agent with the current check over at least one full payment cycle. Measure precision (share of flags that are real duplicates), recall (share of known duplicates found), value stopped and time to decision.
8. Govern the learning. Feed only validated AP decisions back, version every rule or threshold change and have the coach approve it. Send internal audit a monthly control report: population screened, flags, decisions, overrides.

A starter scoring sheet (ours, not DIANA’s)

Signal	Points
Same vendor, same normalised reference	40
Different vendor records sharing tax ID or bank account	30
Same gross amount (after currency conversion)	25
Amount within ±1% or one tax rate apart	10
Document dates within 10 days	10
Same PO and goods receipt already fully invoiced	25
Different intake channels (e.g. EDI and email PDF)	5
Credit note or reversal between the two	−40

Review anything at 70 points or more before the payment run, and sample a few below that every week to see what you miss. Tune the weights on your labelled history, not on intuition.

A concrete example (hypothetical numbers)

The 132,000 invoices a year stated for Village Roadshow work out at roughly 11,000 a month. Imagine a group of that size, with these invented figures:

• A supplier’s invoice “INV-0012” for A$18,450.00 arrives by EDI on 3 March and is posted. On 7 March the same invoice is emailed as a PDF to another division and keyed as “INV0012”. SAP’s exact-match check sees two different references. The scoring sheet gives 40 + 25 + 10 + 5 = 80 points, and the pair goes to the AP queue with both documents side by side. The AP officer blocks the second one.
• Another pair scores 70: two vendor records share a bank account (30), with the same amount (25), dates a week apart (10) and different channels (5). The AP officer releases the invoice (it is a genuine second delivery) but the case is escalated to the master-data owner, who merges the duplicate vendor record. That is the upstream fix ProxyN’s page refers to.
• Over the month, 160 pairs are flagged; 24 are confirmed duplicates worth A$190,000 and 136 are released. Precision is 15%. If the retrospective study suggests there were about 30 duplicates, recall is roughly 80%.

That third bullet is the conversation to have with any vendor: with 11,000 invoices and 30 duplicates, a system that flags nothing at all is “99.7% accurate”.

Stated results

Claim	Figure	Who says it
Invoices screened a year	~132,000 (132,159 on ProxyN’s site)	Session abstract; ProxyN
Annual AP spend covered	A$425 million, four divisions, eight currencies	Session abstract; ProxyN
Detection accuracy	99.4%	Session abstract; ProxyN event page
Time to production	~8 weeks / 12 weeks from first workshop	Abstract / ProxyN customer story
Manual review effort	−60 to 70%	Speaker bio on the event site
Review queue, first four days	−92%	BCS engineer on LinkedIn
Three-year ROI	440%	Speaker bio on the event site

Village Roadshow’s own post gives no figures. ProxyN’s homepage adds an anonymous quote from a “Group AP/AR Manager” of “a leading Australian entertainment group” calling DIANA the most reliable member of the AP team. No source publishes the number of duplicates found, the value stopped, the false-positive rate, how the ROI was calculated or what DIANA costs.

Limitations and risks

• Vendor-heavy evidence. The company confirms the project and its human-in-the-loop design; the numbers come from the builder, its sister company or the abstract of a session at an event the builder sponsors.
• Inconsistent figures. Eight weeks or twelve; 60–70% less effort or a 92% smaller queue. They may measure different things (build versus whole project, steady state versus first days), but nobody says so.
• “Accuracy” is undefined. Without precision and recall on a stated duplicate rate, 99.4% says little, as the example shows.
• “Autonomous” versus “people decide”. The speaker bio calls DIANA autonomous; the company says every flag is reviewed by a person. Both can be true (it runs on its own, decides nothing), but read the boundary before you copy it.
• Learning loops can drift. If released invoices teach the agent that a pattern is fine, a fraudster who gets one through can teach it more. Learning must come from validated decisions only, under change control.
• Alert fatigue. A queue that is 85% false positives trains people to click “release”. Watch release times and sample the releases.
• Unknowns. SAP release, model, hosting, data handling and price are not published. The session on 18 November may add detail; we will update this entry if it does.

Common mistakes

• Relying on the ERP’s exact-match check and calling the control covered.
• Screening after the payment run, when the job becomes recovery instead of prevention.
• Ignoring duplicate vendor records, the most common root cause according to ProxyN.
• Leaving out credit notes, reversals and re-issued invoices, which look like duplicates and flood the queue.
• Checking one company code at a time when the duplicate lands in a sister entity or another currency.
• Letting the agent post or clear anything in the first months.
• Reporting “accuracy” to the audit committee instead of precision, recall and value stopped.

Conclusions

Village Roadshow’s DIANA is a useful reference because it is boring in the right way: one control, one population, a clear owner, evidence on every flag and people making the call. The design is easy to copy on SAP or any ERP with good AP data, and you can start with rules and a spreadsheet before buying an agent platform. What you should not copy is the way the results are reported. Ask for the duplicate rate, precision, recall and value stopped before you believe any accuracy figure, including this one.