AI for Project Financial Report Auditing

An AI-based financial report auditing system reads heterogeneous documents — reports, budgets, scanned attachments, digitally signed files — and automatically checks the consistency between amounts, activities and eligibility rules, returning a traffic-light outcome with supporting evidence. For a non-profit foundation that funds oncology research we built a Proof of Concept of one, applied to a first set of real projects.

The organization grants funds to research projects and has to verify how those funds are reported by the researchers and the funded institutions. It is a delicate control: it concerns the correct use of public and donated resources. And, done by hand, it is also slow and repetitive.

The problem: report auditing is manual, document-heavy and repetitive

For each project and each year, the reviewer has to cross-check several heterogeneous documents — the organization’s and the ministerial reports, applications and renewals, budget reallocations, annual administrative reports, scanned attachments and digitally signed files (.p7m) — and manually verify a long series of consistencies: between reported amounts and approved budget, between activity descriptions and staff qualifications, against cost-eligibility rules and the presence of bioethics authorizations.

It is long, repetitive work that is inherently prone to human error. The difficulty is not the single check, but the volume: dozens of cross-checks, on documents in different formats, repeated for every project and every year.

The solution: a web application that reads documents with AI

We built a web application, deployed in the organization’s Azure tenant, that processes the uploaded documents through an Azure OpenAI LLM. The operator starts a new analysis by selecting researcher, project and year, uploads the reporting documents, the most recent application and any budget reallocations, and receives a structured outcome.

The automatic checks and the traffic-light outcome

The system runs a series of checks: correspondence between report, project and year; distinction between the organization’s and ministerial reports; detection of budget deviations beyond threshold; verification of the textual justifications in the annual administrative report; consistency between the staff cited and the project team; compliance with eligible costs; consistency of activity descriptions with qualifications; presence of bioethics authorizations for experimentation. The outcome is returned with a traffic-light indicator — green, yellow, red — and a detailed evidence report, with a history of the analyses and a detail page for each.

Why without RAG: the prompt-engineering approach

Unlike other projects where we build a RAG-based retrieval engine, here the solution uses no vectorization: it relies on prompt engineering to query the model, directly leveraging its ability to read and extract information from documents — including scanned attachments and signed .p7m files. It is an architectural choice, not a shortcut: when the documents to compare are specific and confined to the single case, direct extraction is easier to govern and to make traceable than building a vector index.

The challenges: reliable extraction and judgment criteria

The most delicate part is not reading a single document, but making extraction reliable across heterogeneous material — including scanned attachments and digitally signed files — and correctly classifying each analysis against project and year. Two knots in particular required work: automatically distinguishing the organization’s reports from the ministerial ones, based on format and amounts, and defining the criteria by which the outcome moves from green to yellow to red. It is not a mechanical threshold: it requires establishing when a deviation or an inconsistency is a simple signal to verify (yellow) and when it is a problem that blocks the case (red), constraining the model’s behavior with explicit guardrails so that the judgment stays predictable and justifiable. Likewise, recognizing the eligible-cost rules and reading the signed .p7m files were refined on the real material of the first projects, where each body reports with its own nuances. This is where AI-based document control becomes truly usable: not in generating text, but in producing an outcome a person can trust and can justify to a reviewer.

A PoC to validate the approach

This first version is a Proof of Concept, applied to a small set of projects chosen by the organization to test the soundness of the approach before extending it. In this phase the supporting data — researchers, projects, years — is set up to simulate the future integration with the organization’s management system. The planned evolution is clear: a scheduled job on Azure Functions, integrated via API with the management software and the document file share, to move the control from assisted to fully automatic end-to-end.

Being a PoC, the benefits are for now qualitative — faster, more uniform and more traceable auditing — and the precise measurement of the impact is part of the next phase, on real volumes.

Who benefits from this approach

This kind of solution is relevant for any organization that has to check, on a recurring basis, the consistency of a set of documents against precise rules: bodies that grant funding and contributions, administrative functions that verify reports and supporting documents, offices that handle document-heavy, control-intensive cases. Wherever the bottleneck is the manual verification of many heterogeneous documents, AI can read, cross-check and flag, leaving the decision to the person. The same document-verification setup underpins the validation of insurance claim documents.

If your organization spends qualified staff time on the manual auditing of reports or document-heavy cases, an AI document processing project can drastically reduce the repetitive work. Contact us for an assessment →