The Growing Value of AI in Finance

Finance teams are increasingly discovering the value of Artificial Intelligence (AI) in their daily operations.

One particularly interesting application is financial reconciliation: comparing invoices, sales transactions, credit card settlements, and bank statements to identify discrepancies.

Traditionally, these activities involve extensive spreadsheet manipulation, complex formulas, manual cross-referencing, and occasionally custom-built software.

With the introduction of Large Language Models (LLMs), finance professionals can now upload files and request complex analyses using natural language.

For example, a finance team can ask:

Compare these sales transactions against the credit card provider settlements and bank statements. Identify missing payments, discrepancies in transaction amounts, and any settlements that have not reached our bank accounts.

The results can be impressive.

AI can understand different data structures, identify relationships between datasets, suggest matching criteria, and produce useful reconciliation reports.

This capability is particularly valuable for organisations where finance professionals may not have extensive programming or data engineering experience.

However, there is an important consideration that becomes increasingly relevant as data volumes grow:

The number of tokens consumed when using AI to process large datasets.

A Realistic Scenario: Reconciling More Than 200,000 Sales Records

Consider a retail business that processes thousands of transactions every day.

At the end of the month, the finance department needs to reconcile the following information:

  1. Sales data: CSV exports containing over 200,000 individual item sales.
  2. Credit card settlements: Files from payment providers containing transaction references, settlement batches, refunds, and processing fees.
  3. Bank statements: Records of deposits received from payment processors.

The objective is to verify that recorded sales correspond to successful payments and that the expected settlement amounts were deposited into the company’s bank accounts.

This process is not necessarily straightforward.

A single customer transaction may contain multiple sales items. Credit card processors may group hundreds or thousands of transactions into a single settlement. Fees may be deducted before funds are deposited, and settlements may occur several days after the original sale.

The reconciliation must account for these differences.

An AI assistant can help analyse the datasets and identify potential discrepancies.

But what happens when the sales file alone contains more than 200,000 rows?

The Hidden Cost: Token Consumption

Large Language Models operate using tokens.

Every prompt, response, and piece of information processed by the language model contributes to token consumption.

Consider a simplified example.

Assume that a CSV file contains 200,000 sales records, with each record averaging approximately 100 characters.

That produces around 20 million characters of raw data.

If this information is passed directly into an LLM’s context, it may represent millions of tokens, depending on how the data is encoded and tokenised.

And this is only the sales file.

Additional datasets include credit card transactions, settlements, and bank statements.

Now imagine running the same reconciliation repeatedly:

  • First, to identify unmatched transactions.
  • Again, to investigate settlement discrepancies.
  • Another time, after correcting errors in the source files.
  • Finally, to generate an updated report for management.

If each operation involves sending large volumes of raw data to the LLM, token consumption can become substantial.

There is also the question of context window limitations.

An LLM cannot necessarily process an arbitrarily large dataset in a single prompt.

Some AI platforms avoid this problem by using Python, SQL, or external data-processing tools behind the scenes. In those cases, the data does not necessarily consume tokens on a row-by-row basis.

Nevertheless, repeatedly using a conversational AI workflow for a deterministic financial process may introduce unnecessary cost and complexity.

This leads to a fundamental question:

Why use AI repeatedly to calculate something when AI could create a tool to perform those calculations automatically?

Changing the Approach: AI as a Software Developer

Instead of asking an LLM to reconcile 200,000 transactions every time, consider using AI to build a dedicated reconciliation application.

The initial request to the AI could be:

Create a Python application that accepts sales transactions, credit card provider settlements, and bank statements in CSV format. The application should reconcile sales against payment transactions, compare settlement batches against bank deposits, identify discrepancies, and generate a structured reconciliation report.

This changes the role of AI.

Rather than using the language model as the engine responsible for repeatedly processing large amounts of financial information, we use it to generate the code responsible for performing the reconciliation.

Once developed and tested, the application can operate independently of the LLM.

The same processing logic can then be executed against new datasets without consuming additional AI tokens.

The Proposed Architecture

The solution can be divided into two distinct stages.

Stage 1: AI-Assisted Development

AI is used to:

  • Understand the structure of the financial datasets.
  • Define the reconciliation rules.
  • Generate the data-processing code.
  • Implement exception handling.
  • Create the reporting functionality.
  • Develop automated tests to validate the results.

The AI may generate a Python application using libraries such as Pandas, Polars, or DuckDB.

The generated code should be reviewed and tested against known financial results before being deployed.

Stage 2: Independent Data Processing

Once the application is ready, the finance team can upload the same types of CSV files used in the original AI analysis.

The tool performs the reconciliation using conventional software processing.

flowchart TD
    Tool["RECONCILIATION TOOL"] --> Sales["Sales CSV<br>200k+ rows"]
    Tool --> CC["Credit Card CSV<br>Settlements"]
    Tool --> Bank["Bank CSV<br>Statements"]

    Sales --> Norm["Data Normalisation"]
    CC --> Norm
    Bank --> Norm

    Norm --> Match["Transaction Matching"]
    Match --> Settle["Settlement Validation"]
    Settle --> Ex["Exception Detection"]
    Ex --> RepGen["Report Generation"]
    RepGen --> Rep["Reconciliation Report"]

All calculations, matching operations, and report generation are performed by the application.

No AI tokens are required during routine execution, provided the application does not make additional calls to an LLM.

How the Reconciliation Tool Would Work

The proposed tool would perform four primary functions.

1. Import and Normalise the Data

Different financial systems often use different field names and data formats.

For example, one system might identify a transaction using transaction_id, while another might use payment_reference.

The tool would standardise these fields, validate the data, and prepare the records for matching.

2. Reconcile Sales Against Credit Card Payments

The application would compare sales transactions against the payment provider records.

Matching rules could include:

  • Transaction references.
  • Payment amounts.
  • Transaction dates.
  • Payment methods.
  • Refunds and reversals.

It is also essential to distinguish individual sales items from payment transactions, as multiple sales items may belong to a single payment.

3. Reconcile Settlements Against Bank Statements

Once the sales and payment transactions have been reconciled, the application would verify that the payment provider settlements correspond to the amounts deposited into the bank.

For example:

Description Amount
Gross credit card sales $150,000.00
Refunds -$2,000.00
Processing fees -$2,300.00
Expected bank settlement $145,700.00
Actual bank deposit $145,700.00
Difference $0.00

In this example, the settlement is fully reconciled.

Any difference between the expected and actual bank deposit would be recorded as an exception for investigation.

4. Generate a Reconciliation Report

The application would produce a structured report showing:

  • Total transactions processed.
  • Total sales and payments reconciled.
  • Unmatched transactions.
  • Missing settlement batches.
  • Differences between expected and actual bank deposits.
  • Exceptions requiring manual investigation.

Reports could be generated as CSV, Excel, HTML, or PDF files.

Importantly, the same logic would be applied consistently every time the tool runs.

Comparing the Two Approaches

Feature AI Data Processing AI-Generated Reconciliation Tool
Main role of AI Analyse financial data Develop processing software
Large dataset handling Depends on LLM and platform tools Conventional processing engine
Tokens per reconciliation Potentially significant Zero without runtime LLM calls
Repeated execution May require additional AI interactions Run the same application
Processing consistency Depends on implementation Deterministic with fixed rules
Auditability Requires suitable traceability controls Can provide source-level audit trails
Scalability Depends on platform architecture Depends on available computing resources
Maintenance Prompts, workflows, and tools Application code and business rules

The objective is not to suggest that AI cannot process large datasets effectively.

Modern AI platforms can use external tools and code execution environments to handle complex analytical tasks.

Rather, the argument is that stable and repeatable financial reconciliation rules are better implemented as reusable software than repeatedly expressed through conversational prompts.

The Economics of Reusable Code

Consider a finance team that executes reconciliation reports every day.

With a token-intensive AI approach, processing costs may increase with the number of reports, the amount of data sent to the model, and the complexity of interactions.

With an AI-generated application, the economic model changes.

There is an initial investment in defining the requirements, generating the code, validating financial calculations, and testing the application.

However, after deployment, the same application can process new data repeatedly.

For example:

flowchart TD
    Dev["AI-Assisted Development"] --> Gen["Initial Code Generation"]
    Gen --> Test["Testing and Validation"]
    Test --> App["Production Application"]
    App --> D1["Day 1 Reconciliation"]
    App --> D2["Day 2 Reconciliation"]
    App --> D3["Day 3 Reconciliation"]
    App --> DN["Day N Reconciliation"]

Each execution uses the existing software rather than requesting a new reconciliation from the LLM.

The application still consumes computing resources, and it requires maintenance, monitoring, and occasional updates.

But routine processing no longer depends on token consumption.

For high-volume, frequently repeated tasks, this can represent a meaningful operational advantage.

AI Still Has an Important Role

The intention is not to eliminate AI from financial reporting.

Instead, AI can be used more selectively.

After the reconciliation application processes the data, it can produce a compact summary containing the most relevant information.

For example:

Metric Value
Sales items processed 215,432
Payment transactions 137,850
Matched payment transactions 137,721
Unmatched transactions 129
Settlement batches matched 486
Unmatched settlement batches 3
Largest discrepancy $8,450.00
Status Investigation Required

The numbers above are illustrative.

This summary could then be provided to an AI assistant for interpretation.

Instead of processing hundreds of thousands of raw records, the LLM would work with a much smaller set of results.

It could help the finance team:

  • Identify patterns in reconciliation discrepancies.
  • Suggest likely causes of missing settlements.
  • Prioritise exceptions for investigation.
  • Generate executive summaries.
  • Recommend improvements to reconciliation rules.

This is a more efficient division of responsibilities.

Let conventional software perform the calculations. Let AI help develop the software and interpret the results.

Beyond Finance: A Broader Opportunity

Financial reconciliation is only one example of how organisations can rethink their use of AI.

Many business processes involve repeated calculations and predictable rules.

Examples include inventory reconciliation, payroll validation, invoice matching, sales reporting, commission calculations, and operational performance analysis.

In each case, AI can help define the requirements and generate software that automates the process.

Rather than using AI as a permanent intermediary for every calculation, organisations can use AI to create tools that become part of their operational infrastructure.

This introduces a useful distinction:

AI for execution versus AI for creation.

Both approaches have value, but they solve different problems.

AI execution is particularly useful when tasks require flexible interpretation, natural-language understanding, or dynamic reasoning.

AI-assisted code generation is particularly valuable when tasks are repetitive, rules are well defined, and processing must be consistent, scalable, and auditable.

Conclusion: Spend Tokens Building Solutions, Not Repeating Calculations

Artificial Intelligence has made financial analysis significantly more accessible.

Finance teams can now explore datasets, identify discrepancies, and develop automation ideas without necessarily having extensive software development expertise.

However, as datasets become larger and reporting requirements more frequent, the way AI is integrated into the workflow matters.

Using LLMs to repeatedly process large volumes of financial transactions may not always be the most efficient architecture.

An alternative is to invest AI capabilities in generating a dedicated application that performs the reconciliation independently.

The result is a reusable tool capable of processing hundreds of thousands of records, applying consistent financial rules, and generating reports without consuming AI tokens during routine execution.

The broader lesson extends beyond financial reconciliation.

The greatest value of AI is not necessarily in having it perform every task. Sometimes, the greatest value comes from having AI build the tools that perform those tasks for us.

And when those tools can be reused thousands of times, the value of that initial AI investment becomes considerably more compelling.