Financial reporting holds a special place in a finance department. It is expected on a set date, reviewed by executive management, and sometimes by a board of directors, shareholders or banks. Each cycle calls on the same people for the same tasks: gathering the figures from the entities, checking them, explaining variances, drafting the commentary and formatting the presentations. A large share of this time goes into preparation, and only a small share into the analysis that truly matters to readers.
This is precisely where artificial intelligence (AI) attracts interest. A tool capable of drafting a first version of the commentary, spotting an unusual variation or answering a question about the month's figures promises to give time back to the team. But reporting is also where an error costs the most: a wrong figure in a board presentation, a commentary that contradicts the accounts, sensitive information that leaves its intended scope. The challenge, therefore, is not to automate as much as possible, but to choose what to entrust to the tool, what to keep, and how to exercise control.
This guide is intended for CFOs, heads of financial control and consolidation, and executives who want to understand what AI can bring to reporting without undermining its reliability. It describes the uses worth examining, the conditions to put in place, how to choose a first use case and the validation rules to write down before starting. The examples are generic: they name no company, person or tool.
What financial reporting covers#
The term covers several exercises that do not carry the same requirements. Management reporting, most often monthly, is used to steer the business: it compares actuals with the budget and forecasts, explains variances and informs management's decisions. Consolidated reporting brings together the accounts of several entities under common rules and prepares the financial statements. Reporting to shareholders, lenders or the board takes some of these figures and presents them in a format intended for external readers or governance bodies. Depending on the company, specific reports are added to these: cash, banking commitments, sustainability information.
These exercises share a common chain: source data, adjustments, controls, formatting and commentary. They differ in how demanding they are. An internal dashboard can tolerate a flagged approximation; a document handed to a lender or published cannot. Before talking about AI, you therefore need to know which reporting is in question, who reads it, and what an error costs each of its readers.
Where the time goes in a reporting cycle#
In most finance departments, the time spent on a cycle is divided between a few broad families of tasks. Collection involves obtaining the submissions from the entities, systems and operational staff, chasing those who are late and checking that the files received are complete. Controls cover the consistency of the figures with one another, with the previous period and with the budget. Reconciliations link sources that should agree but do not always do so. Explaining variances requires seeking information from operational staff. Drafting the commentary turns these explanations into readable text. Finally, formatting adapts the whole package to each recipient.
It is useful to measure this breakdown before any project, even roughly. It often shows that the time does not go where people think it does. A team may believe that drafting the commentary is its main burden, and discover that chasing reminders and reworking badly completed files consume the most time. This measurement then serves as the starting point for judging what AI will really have changed.
AI uses worth examining#
The uses below are possibilities to assess in your own context, not guaranteed results. Each one assumes reliable data upstream and human control downstream.
Checking submissions from the entities#
A tool can check that a file received is complete, that the amounts follow the expected formats, that the totals are consistent and that variations from the previous period stay within limits defined in advance. It does not replace the controls programmed into the systems, but it can process the files that circulate outside those systems, which are often numerous. The expected benefit is to detect anomalies earlier, before they feed through into the consolidation.
Reconciliations and justification of variances#
For reconciliations between two sources, a tool can suggest matches, isolate unreconciled items and prepare a list of differences to be justified. For explaining management variances, it can gather the available information, such as the entities' comments, volumes or known events, and propose an initial explanation for the team to check. The judgement on what is significant remains a human one.
Management commentary#
This is the most visible use. Starting from validated figures and the explanations gathered, a language model can produce a first draft of the commentary, harmonise the style from one entity to the next and adapt the level of detail to the reader. Two conditions are essential. The model must work only on figures that have already been validated, and it must not invent explanations: every cause mentioned must come from information that has been supplied. A plausible but wrong commentary is more dangerous than no commentary at all.
Answering management's questions#
Between two cycles, management asks questions: why has this margin fallen, which entity accounts for this variance, what would a given assumption produce. An assistant that queries the reporting data can prepare an answer, provided it cites the figures it relies on and flags when information is missing. This use calls for particular attention to access rights: not everyone should be able to query all the data.
Preparing presentations#
Formatting for a committee or a board takes time and is repetitive. A tool can prepare the structure, carry over the charts from the validated data and propose a summary. The final review, which checks consistency between the figures, the charts and the text, remains indispensable.
What AI must not do in reporting#
Some limits apply whatever the tool. A published figure must come from the reference systems, never from generated text: if a model rewords a table, it may alter an amount without anyone noticing. A commentary must never attribute a cause that has not been verified. An estimate must not be presented as an actual. And no AI output should go to an external reader without having been validated by a named person.
These limits are not a matter of excessive caution. They stem from the very role of reporting, which is to give a faithful and verifiable picture of the business. A tool that makes reporting faster but less verifiable destroys its very reason for being.
Reference data before the tool#
An AI project applied to reporting quickly reveals the state of the data. If two systems give two different figures for the same aggregate, the tool will not know which one to believe, and it may mix them up. Before deploying anything, you therefore need to know, for each item of data used, which source is authoritative, who is responsible for it and at what point it is frozen for the period.
This work is not specific to AI, but AI makes it urgent. It is often an opportunity to document implicit rules: adjustments made by hand, reclassifications, exceptions known only to a few people. This documentation benefits the whole team, with or without a tool, and reduces dependence on those who alone hold the knowledge of a process.
The audit trail and internal control#
Reporting forms part of an internal control framework. The statutory auditors, internal audit or the audit committee expect every figure to be traceable back to its source, and every control to be documented. Introducing an AI tool must not break this chain.
In practice, for each use you need to be able to answer a few questions: what data did the tool receive, what instruction was it given, what output did it produce, who validated it, and what was changed before validation. Retaining these elements makes it possible to explain an error if one occurs, to monitor the tool's quality over time and to show the auditors that human control is real. It is useful to involve internal audit and, where applicable, the statutory auditors from the design stage, rather than presenting them with a system that is already in place.
Starting from a measured starting point#
To know whether AI has changed anything, you need to know where you are starting from. The starting point is measured over several cycles before the project: the time spent per task, the lead time between the close and distribution, the number of corrections after distribution, the number of back-and-forth exchanges with the entities. The indicators must be defined in writing, with their method of calculation, so that the comparison between before and after is honest.
You also need to measure quality, not just speed. Reporting that is produced faster but corrected more often is not progress. Corrections after distribution, management questions left unanswered and discrepancies between commentary and figures are good indicators of quality.
Choosing the first use case#
The first use case often determines how the rest of the project unfolds. If it fails, the team loses confidence; if it succeeds on too narrow a scope, it convinces no one. A few criteria help with the choice.
The case must be repetitive, so that the benefit recurs with every cycle. It must be clearly delimited, with clear inputs and outputs. Its data must exist and be reliable. Its risk must be under control: an error must be detectable before distribution. Finally, the time it consumes today must be measurable.
In many finance departments, the first draft of the commentary for an internal report meets these criteria: it is repeated, it starts from validated figures, and it is reviewed before distribution. Checking the completeness of the submissions from the entities is another. Conversely, an assistant open to the entire department to query all of the data is rarely a good first case: its scope is broad, its access risks are high and its quality is difficult to measure.
Organising human validation#
Human validation cannot simply be decreed; it has to be organised. For each use, you need to write down who validates what and against which criteria. The financial controller who reviews a commentary must know what they are checking: consistency with the figures, the accuracy of the causes cited, the absence of information that should not appear. A review without criteria quickly becomes a validation in name only.
You also need to plan for the case where the output is poor. What does the team do if the proposed commentary is wrong: correct it, report it, revert to the previous method? This feedback is valuable for improving the tool and monitoring its quality. Finally, the review workload must be counted against the benefit: if reviewing and correcting takes as long as drafting, the use adds nothing.
Confidentiality, inside information and the regulatory framework#
Reporting data is sensitive. Before publication, the results of a listed company may constitute inside information within the meaning of the EU Market Abuse Regulation, which requires control over who has access to it. For an unlisted company, the figures remain confidential with regard to competitors, partners and sometimes employees. You therefore need to know where the tool processes the data, who can access it at the provider, and whether the data is used to train models.
The General Data Protection Regulation (GDPR) applies as soon as reporting contains personal data, which happens with payroll, remuneration or named information about teams. The European regulation on artificial intelligence, often referred to as the EU AI Act, sets out obligations according to the risk level of systems. Most reporting uses fall within limited risk levels, but the classification must be carried out and documented, ideally with a lawyer. These points do not block a project; they are better dealt with at the scoping stage than after deployment.
Training the finance team#
A tool that is poorly understood is poorly used. Training for a finance team works best when it focuses on the team's own tasks and documents rather than on generic examples. It should cover three subjects: what the tool can and cannot do, how to phrase a request and check an output, and the company's usage rules, that is to say the authorised data, the authorised tools and the mandatory validations.
Training is also an opportunity to gather objections. The people who produce the reporting know its weak points better than anyone; their doubts about the reliability of a use are often well founded and should inform the validation rules.
Pitfalls to avoid#
The first pitfall is automating a poorly documented process: the tool then reproduces the existing approximations, only faster. The second is measuring only the time saved, without looking at quality or the review workload. The third is letting a tool reword tables of figures, which introduces errors that are hard to spot. The fourth is opening up broad access to the data too early, before rights have been defined. Finally, the fifth is presenting potential gains to the committee as realised gains.
Each of these pitfalls has a simple remedy: document before automating, measure quality alongside speed, work only on validated figures, limit access, and clearly distinguish what has been measured from what is estimated.
Glossary#
- Management reporting: periodic presentation of results compared with the budget and forecasts, intended for internal steering.
- Consolidation: combining the accounts of several entities under common rules, with the elimination of transactions between them.
- Reference data: the version of a piece of information that is authoritative within the organisation, with an identified owner.
- Audit trail: the ability to trace a figure or a decision back to its source and to the controls that validated it.
- Management commentary: text that explains the figures and their variances to the readers of the reporting.
- Inside information: precise, non-public information which, if it were made public, would be likely to have a significant effect on the price of a financial instrument.
- Measured starting point: the state of a process before the project, established with written indicators and a written method of calculation.
- Usage rules: rules that state which tools are authorised, with which data, and who validates their outputs.
Printable checklist#
This list helps you prepare an AI project applied to reporting. It does not replace the advice of a lawyer or that of your auditors.
Before you start#
- The reporting concerned is identified, along with its readers and the cost of an error for each of them.
- The breakdown of time by task has been measured over several cycles.
- For each item of data used, the authoritative source and its owner are known.
- Speed and quality indicators are defined in writing, with their method of calculation.
Before you deploy#
- The tool works only on validated figures.
- Mandatory validations are written down: who validates what, against which criteria.
- Inputs, instructions, outputs and validations are retained for the audit trail.
- Where the data is processed and what access the provider has are known.
- The classification under the EU AI Act and the GDPR is documented.
- Internal audit and, where applicable, the statutory auditors have been consulted.
After launch#
- Corrections made to outputs are recorded and analysed.
- The review workload is counted against the benefit.
- Results presented to the committee distinguish what was measured from what was estimated.
Frequently asked questions#
Can AI produce the reporting in place of the team?#
No. It can prepare, check and draft a first version, but the figures come from the reference systems and the content distributed is validated by the team. Reporting commits the finance department, which remains responsible for its accuracy.
Which use should you start with?#
With a repetitive, clearly delimited use that starts from validated figures and is reviewed before distribution. The first draft of the commentary for an internal report, or checking the completeness of the submissions from the entities, often meets these conditions.
Do you need to change your consolidation system to use AI?#
Not necessarily. Most uses rely on existing data. However, an AI project often reveals inconsistencies between sources, which must be dealt with before deployment.
How should the auditors be involved?#
By consulting them from the design stage and by retaining, for each use, the data received, the instruction, the output, the validation and the corrections. A documented system is easier to present than a tool that is already in place.
How can you tell whether AI has really saved time?#
By comparing indicators measured before and after, using the same method, and by counting the review workload. A gain that disappears into corrections is no gain at all.
Conclusion#
AI can give a finance department back part of the time that reporting consumes in preparation, so that it can be reinvested in analysis. It only does this well if the reference data is clear, if uses are chosen for their value and their risk, and if human validation is organised rather than assumed. The safest approach is to start from a measured starting point, begin with a limited use that is reviewed, and then extend what has proved its worth.