Artificial intelligence has become one of the most frequently discussed topics in enterprise finance.
The conversation usually begins with automation, productivity, and the possibility of generating faster insights. However, in the finance transformation projects I have worked on, the more important question has always been much more practical.
Finance organizations rarely suffer from a shortage of AI ideas. What they often lack is clarity on where AI can deliver measurable business value.
The more difficult challenge is selecting the right use case, establishing a defensible baseline, preparing the data, integrating the technology into existing controls, and persuading users to trust the resulting recommendations.
Through my work on SAP finance transformation, reporting, analytics, process standardization, and data governance initiatives, I have learned that the most successful AI implementations are not necessarily the most ambitious. They focus on a clearly defined business problem and a well-understood transaction population. They also establish measurable outcomes before implementation begins.
This article examines three areas in which I have seen AI and intelligent automation create practical value:
The first two examples include measured outcomes from anonymized implementations in which I participated. The third examines how finance teams can apply similar implementation discipline to analytical use cases.
I will also explain what did not work as easily as expected. In my experience, AI projects in finance are rarely delayed by the algorithm alone. They become difficult because of inconsistent data, unclear process ownership, fragmented business rules, control requirements, and insufficient user trust.
Cash application is one of the strongest starting points for finance AI because both the problem and the value can be measured.
Incoming customer payments do not always contain enough information to identify the invoices being paid. A customer may settle several invoices with one payment, make a partial payment, deduct a disputed amount, use an inconsistent reference, or omit remittance information entirely.
Rules-based processing can resolve predictable cases, but the remaining exceptions often require experienced analysts to investigate bank-statement information, remittance documents, customer accounts, and open receivables.
SAP Cash Application uses machine learning to support the matching of incoming payments to open receivables. The solution draws on historical clearing information and accountant behavior to inform future matching decisions. In the standard integration model, incoming-payment and open-invoice information is passed from SAP S/4HANA to a matching engine on SAP Business Technology Platform (SAP BTP).
SAP delivers this as scope item 1MV, Cash Application Integration, and the relevant license or entitlement has to be validated. Commercial packaging should therefore be confirmed for the specific SAP landscape and contract rather than assumed to be included with every SAP S/4HANA deployment.
The solution assessment we ran in December 2024 confirmed that the machine-learning engine would be hosted on SAP BTP and integrated with SAP S/4HANA, and flagged pricing and licensing for commercial review.
In one anonymized implementation, the finance organization wanted to increase the proportion of incoming customer payments that could be matched automatically to open invoices.
Before implementation, the automatic matching rate for the agreed in-scope payment population was 58%.
We ran the project as a business-process improvement initiative supported by machine learning, not as a technology deployment exercise.
We first analyzed the unmatched population and separated the exceptions into categories, including:
We then reviewed historical clearing decisions, identified recurring patterns, standardized portions of the process, and introduced machine-learning-supported matching for the defined scope.
Following implementation and stabilization, the automatic matching rate increased from 58% to 84%.
This was a 26-percentage-point improvement for the measured in-scope population. I prefer to describe the result in percentage points because that is clearer than presenting it as a relative percentage increase.
The 84% result should not be interpreted as a claim that every payment across the organization was automatically cleared. It was measured for the payment population included in the implementation, using the organization’s agreed matching criteria and measurement period.
There were a number of things that we thought would be easier than they ended up being.
A machine-learning model can learn from historical clearing behavior, but historical activity is useful only if the past decisions were consistent and correct.
We found that accountants sometimes handled similar exceptions differently. In other cases, clearing decisions relied on knowledge held by experienced analysts but not documented in the process.
Before relying on historical data, we had to distinguish useful patterns from inconsistent manual decisions.
AI improved matching, but it could not manufacture information that had never been supplied.
Payments with missing references, unclear deductions, or unresolved commercial disputes continued to require investigation. Some exceptions that initially appeared to be matching problems were actually upstream customer-service or collections issues.
Payment behavior was not uniform. Reference formats, banking practices, remittance quality, and deduction behavior varied across customer and business segments.
A matching pattern that performed well for a predictable customer population did not necessarily transfer to a more fragmented or irregular population.
Experienced analysts did not immediately accept system-generated recommendations. During the early stages, many users rechecked proposed matches manually.
This reduced the initial productivity benefit, but it was a necessary part of building trust. Adoption improved after the system demonstrated consistent results and users understood when a recommendation should be accepted, reviewed, or rejected.
The increase from 58% to 84% did not result from machine learning alone. It resulted from combining the technology with better historical data, exception segmentation, defined confidence thresholds, clearer process ownership, and user involvement.
For organizations evaluating SAP Cash Application, I recommend establishing the following baseline measures before implementation:
Without these measures, an organization may deploy the technology successfully but remain unable to demonstrate its business value.
Invoice processing is another practical AI opportunity because accounts payable teams continue to receive documents in many different formats, including PDFs, scanned images, email attachments, supplier-specific layouts, and image files.
Even where SAP S/4HANA manages financial posting, approvals, tolerances, and accounting controls, capturing accurate information from the incoming document can remain a significant bottleneck.
SAP Document AI is SAP’s solution for AI-supported document processing. Within invoice processes, Document Information Extraction can be used to extract information after an invoice is uploaded.
The service can extract a defined collection of invoice information and can use templates or learning methods to improve extraction. Extraction performance can vary by language and country or region, and the treatment of low-confidence values depends on process configuration.
SAP Document AI is offered as an SAP BTP service with free, base, premium, and embedded-edition service plans, and productive use requires a paid enterprise account. Customers should confirm the applicable service plan, quota, region, integration design, and commercial entitlement for their intended use.
Availability should not be described through one universal SAP S/4HANA release number because SAP Document AI is a cloud service on SAP BTP and can be integrated into different invoice-processing architectures. At the time of implementation planning, the relevant SAP BTP region, service plan, supported document type, invoice solution, and SAP S/4HANA integration scenario should all be verified.
In a second anonymized implementation, the accounts payable organization introduced intelligent document extraction into an existing invoice-processing workflow.
The objective was to reduce manual entry while preserving the controls required for validation, approval, tax treatment, purchase-order matching, and posting.
After implementation and stabilization:
These two measures describe different outcomes.
The 72% result measured the proportion of in-scope invoices for which the required header information passed through the extraction stage without manual data entry. It should not be described as a 72% fully touchless invoice rate unless the same invoices were also validated, approved, and posted without accounts-payable intervention.
This distinction is particularly important in invoice automation.
On one invoice-automation initiative we distinguished between touchless extraction, where the extracted data does not require AP review, and a touchless invoice, where the document is extracted, validated, and posted to SAP without AP review.
The 43% cycle-time reduction measured the change in average elapsed processing time for the agreed population. It did not imply that every invoice became 43% faster or that document extraction was the sole cause. Workflow improvements, exception handling, data quality, and process standardization also contributed.
Similar to use case 1, there were a number of things we learned that were more difficult than expected.
One of the most important lessons was that high field-level accuracy does not automatically create a touchless invoice.
An invoice may contain many correctly extracted fields, but if one critical field is incorrect or missing, the document may still require manual review.
The project therefore had to define:
Implementation testing also demonstrated the practical burden created by missing mandatory information. In one 100-invoice test set, 73 invoices were reconciled successfully, 26 could not be reconciled because mandatory line-item information was missing, and one document with approximately 110 line items required substantial manual correction.
This illustrates why a single accuracy percentage can be misleading. Document complexity and the importance of the mis-extracted field matter as much as the number of fields extracted correctly.
The solution performed most consistently for high-volume suppliers with repeatable invoice formats.
Lower-volume suppliers and documents with unusual structures created a disproportionate number of exceptions. Image quality, spacing, line-item formatting, decimal presentation, and changing supplier layouts all affected the results.
Correctly extracting an invoice number, amount, currency, or supplier did not guarantee successful posting.
The invoice could still fail because of:
The wider business process for invoice verification and posting includes data enrichment, tax determination, purchase-order and non-purchase-order business rules, approvals, and final posting.
Document extraction was not a one-time configuration exercise.
Supplier layouts changed. New suppliers entered the process. Exceptions needed to be reviewed, corrections recorded, and performance monitored. Without clear ownership for template maintenance, correction quality, and model improvement, the initial gains could deteriorate.
The 72% no-manual-entry result and 43% cycle-time reduction were meaningful, but they did not come from switching on an extraction service.
They came from combining extraction with:
Invoice automation should be measured through more than one KPI. Useful measures include:
Treating extraction accuracy as the only success measure can conceal problems elsewhere in the process.
Operational use cases such as cash application and invoice extraction are attractive because they involve repeatable transactions and measurable exception volumes.
Financial analysis and management reporting are more difficult.
Controllers and reporting teams spend significant time comparing actuals with budgets or forecasts, investigating variances, identifying root causes, preparing commentary, and responding to questions from business leaders.
SAP customers may evaluate capabilities across SAP S/4HANA embedded analytics, SAP Analytics Cloud, and Joule-enabled experiences, depending on their architecture and currently available functionality.
I would not describe Joule as a replacement for the underlying reporting model or the controller’s judgment. Its potential value lies in helping users interact with approved business information and focus their attention on material changes. Availability must be verified for the specific SAP product, release, scenario, and customer entitlement.
In reporting-transformation work, I learned that the most valuable starting point was not asking, “What can generative AI write for us?”
The better questions were:
The desired outcome was a more efficient and controlled route from an identified variance to a defensible business explanation, not automatically generated commentary.
Here is what ended up being more difficult than we thought.
Terms such as revenue, margin, operating expense, working capital, and forecast accuracy were not always calculated consistently.
An AI-assisted explanation cannot be more reliable than the semantic and reporting model behind it.
Changes to cost-center, profit-center, product, customer, and management-reporting hierarchies created apparent variances that were caused by structural changes rather than business performance.
These issues needed to be resolved before automated commentary could be trusted.
A fluent explanation can create an impression of certainty. Finance users therefore need access to the source measure, comparison period, materiality rule, contributing dimensions, and supporting transaction detail.
For finance, explainability is not optional. A plausible narrative without traceable evidence is not a controlled management report.
Technology could help identify large movements, recurring patterns, or unusual combinations. It could not determine the commercial significance of every movement.
Controllers still needed to distinguish timing effects from structural changes, assess whether an issue would persist, and explain the actions management should take.
AI-assisted reporting should begin with governed metrics and a controlled analytical workflow.
I recommend starting with one recurring report or variance category and measuring:
The objective should be to improve the quality and speed of analysis, not merely to generate more narrative.
Across the three implementations we discussed in this article, I saw the same pattern repeatedly:
AI did not eliminate finance data-quality problems. It exposed them sooner and at greater scale.
Cash application depended on reliable customer accounts, payment references, remittance information, and historical clearing decisions.
Invoice extraction depended on document quality, critical-field definitions, supplier master data, purchase-order references, tax requirements, and downstream controls.
Financial analysis depended on governed KPIs, consistent hierarchies, comparable periods, trusted source systems, and traceable business definitions.
The largest effort often sat outside the AI component itself. We had to address ownership, standardize decisions, define exceptions, improve data, and agree on the circumstances under which automation was safe.
This changed how I evaluate AI opportunities. I no longer begin with the technology. I begin with four things:
Only then do I assess which SAP capability is appropriate.
Before approving an AI initiative in SAP finance, I recommend asking:
“Improve productivity” is not specific enough. The problem should be expressed through a measurable process outcome.
Measure current automation, exception volume, manual effort, cycle time, error rate, and backlog before implementation.
Historical transactions may contain inconsistent decisions, workarounds, and unresolved data-quality problems.
Confidence thresholds should reflect financial risk, materiality, controls, and the cost of an incorrect decision.
Someone must own exception categories, model or template corrections, KPI monitoring, access, thresholds, master data, and user feedback.
My experience implementing AI-supported finance processes has reinforced a simple lesson: successful AI adoption is fundamentally a finance transformation and data-governance challenge, not just a technology initiative.
SAP Cash Application helped increase the automatic matching rate for an in-scope payment population from 58% to 84%. Intelligent document extraction helped 72% of an in-scope invoice population proceed without manual header-level data entry and contributed, together with process improvements, to a 43% reduction in average processing cycle time. These are not hypothetical examples. They are measured outcomes from implementations in which I was directly involved.
Those outcomes were real, but the technology did not achieve them by itself.
The difficult work involved preparing historical data, defining measurable populations, distinguishing true business disputes from matching exceptions, standardizing decisions, improving master data, designing controls, managing low-confidence results, and building user trust.
The strongest AI use cases in SAP finance are not necessarily the most futuristic. They are the ones where the business problem is clear, the existing performance can be measured, the data can be governed, and finance professionals remain accountable for the outcome.
The future of finance will not be defined by automation alone. It will be defined by how effectively finance organizations combine trusted data, disciplined processes, appropriate SAP capabilities, and professional judgment to make better decisions faster.
The implementation examples in this article are drawn from finance transformation initiatives in which I participated directly as part of SAP finance transformation and reporting programs.
Client names, countries, business-unit identifiers, transaction volumes, and other potentially identifying details have been withheld or generalized to protect confidentiality.
The reported metrics reflect measured outcomes for defined project populations and measurement periods. They are not SAP benchmarks, product-performance guarantees, or predictions of results for other organizations. Outcomes will vary according to solution scope, transaction characteristics, historical-data quality, process maturity, configuration, governance, and user adoption.
SAP product availability, deployment options, commercial packaging, service plans, and licensing can change. Organizations should confirm current functionality and entitlements using the latest SAP product documentation and their individual SAP agreements before making implementation decisions.
This post was originally published 8/2026.