I Replaced 3 Manual SAP Reports with AI Agents — Here's the ROI

The Reports That Were Eating My Team's Week

Every Monday morning, three analysts on my team would open SAP GUI and begin a ritual that consumed roughly 22 hours of collective work each week. They'd run transaction MB52 to pull warehouse stock values across 14 plants, export to Excel, cross-reference with open purchase orders from ME2M, then manually build a coverage analysis. A second analyst would pull customer open items via FBL5N for accounts receivable aging, clean up the data, apply business rules for escalation categories, and email the results to regional controllers. The third would generate a procurement compliance report by comparing ME2M purchase orders against negotiated contract prices in ME33K.

These weren't vanity reports. Finance relied on the AR aging for cash flow projections. Supply chain used the stock coverage report to make daily replenishment decisions. Procurement needed the compliance report for quarterly audits. The reports mattered — what didn't make sense was having skilled analysts spend their mornings copying data between SAP and Excel.

Over Q3 and Q4 of 2025, I replaced all three reports with AI agents that pull data directly from SAP, apply business logic, generate the analysis, and distribute the results automatically. Here's exactly how each one works, what it cost, and the measurable ROI.

Report #1: Warehouse Stock Coverage Analysis (MB52 + ME2M)

What the Manual Process Looked Like

The analyst would log into SAP GUI every Monday and Wednesday, run transaction MB52 (Warehouse Stocks) filtered by plant and storage location. For our setup, that meant 14 plants, each with 3-8 storage locations. She'd execute the report, export it to a local spreadsheet using the ALV grid export function (List > Export > Spreadsheet), then do it again for the next plant.

After collecting all the stock data, she'd switch to ME2M (Purchase Orders by Material) to pull open POs with delivery dates in the next 30 days. This required another round of exports — filtering by plant, document type (NB for standard POs, UB for stock transfer orders), and removing completed items.

Then came the actual analysis: calculating days of coverage by dividing current stock by average daily consumption (which she pulled from MC.9 — material consumption statistics), flagging items below safety stock thresholds, and highlighting materials with no incoming supply in the pipeline.

Total time: approximately 8 hours per week.

The AI Agent That Replaced It

The agent runs on a Python backend with scheduled execution via APScheduler. It connects to SAP via RFC using the PyRFC library, which gives direct access to BAPIs and function modules — far more efficient than scraping the GUI or using OData for high-volume data extraction.

from pyrfc import Connection
import pandas as pd

def get_warehouse_stocks(conn, plants):
    # Pull stock data equivalent to MB52
    stocks = []
    for plant in plants:
        result = conn.call('BAPI_MATERIAL_STOCK_REQ_LIST',
            PLANT=plant,
            MATERIAL='',  # all materials
            RAW_DATA='X'
        )
        for item in result['STOCK_REQ_LIST']:
            stocks.append({
                'plant': plant,
                'material': item['MATERIAL'],
                'storage_loc': item['STGE_LOC'],
                'unrestricted': float(item['UNRESTRICTED']),
                'in_quality': float(item['QUAL_INSP']),
                'blocked': float(item['BLOCKED']),
                'unit': item['BASE_UOM']
            })
    return pd.DataFrame(stocks)

def get_open_purchase_orders(conn, plants):
    # Pull open POs equivalent to ME2M
    pos = []
    for plant in plants:
        result = conn.call('BAPI_PO_GETITEMS',
            PLANT=plant,
            DOC_TYPE='NB',
            ITEMS_OPEN_ONLY='X'
        )
        for item in result['PO_ITEMS']:
            if float(item['STILL_TO_DL']) > 0:
                pos.append({
                    'plant': plant,
                    'po_number': item['PO_NUMBER'],
                    'material': item['PUR_MAT'],
                    'quantity_open': float(item['STILL_TO_DL']),
                    'delivery_date': item['DELIV_DATE'],
                    'vendor': item['VENDOR']
                })
    return pd.DataFrame(pos)

The AI component comes in at the analysis layer. Instead of hard-coded rules for flagging issues, I trained a classification model on 18 months of historical stock-out events. The model considers current stock levels, consumption velocity, lead times from the material master (table MARC, field PLIFZ for planned delivery time), seasonal patterns, and open PO reliability (what percentage of POs from each vendor actually arrive on time, pulled from EKBE — purchase order history).

def calculate_coverage_with_ai(stocks_df, orders_df, consumption_df, model):
    # AI-enhanced coverage analysis
    merged = stocks_df.merge(consumption_df, on=['plant', 'material'], how='left')
    merged = merged.merge(
        orders_df.groupby(['plant', 'material']).agg(
            incoming_qty=('quantity_open', 'sum'),
            earliest_delivery=('delivery_date', 'min')
        ).reset_index(),
        on=['plant', 'material'], how='left'
    )

    # Calculate basic coverage days
    merged['daily_consumption'] = merged['avg_monthly_consumption'] / 30
    merged['coverage_days'] = merged.apply(
        lambda r: r['unrestricted'] / r['daily_consumption']
        if r['daily_consumption'] > 0 else 999, axis=1
    )

    # AI prediction: probability of stock-out in next 14 days
    features = merged[['coverage_days', 'incoming_qty', 'vendor_reliability',
                        'seasonal_factor', 'consumption_volatility']].fillna(0)
    merged['stockout_probability'] = model.predict_proba(features)[:, 1]

    # Classify risk
    merged['risk_level'] = merged['stockout_probability'].apply(
        lambda p: 'CRITICAL' if p > 0.7 else ('WARNING' if p > 0.4 else 'OK')
    )

    return merged

The agent formats the results as an interactive HTML report and emails it to the supply chain team, with critical items highlighted at the top. It also pushes CRITICAL items to a Microsoft Teams channel via webhook.

ROI for Report #1

The big win here wasn't the labor savings — it was the stock-out reduction. The AI model catches risk patterns that humans miss because it processes all 14 plants simultaneously and considers cross-plant transfer possibilities. When Plant 1200 is running low on a material but Plant 1400 has excess, the agent flags the transfer opportunity. The analyst never had time to do cross-plant analysis manually.

Report #2: Accounts Receivable Aging (FBL5N)

The Manual Process

Every Tuesday and Thursday, an analyst would run FBL5N (Customer Line Items) for each company code (we operate five). He'd set the parameters to show open items only, sort by net due date, export to Excel, and then apply a complex set of business rules:

• Items 1-30 days past due: "Reminder" category, no escalation
• Items 31-60 days past due: "Follow-up" category, email to sales rep
• Items 61-90 days past due: "Escalation" category, email to sales manager + regional controller
• Items 90+ days past due: "Critical" category, email to VP Sales + Finance Director
• Special rules: government customers get 15 extra grace days, customers with payment plan agreements are excluded, items under €500 are batched into a separate summary

He'd also pull payment history from table BSAD (cleared customer items) to calculate each customer's average payment behavior — do they typically pay on time, 10 days late, 30 days late?

Total time: approximately 6 hours per week.

The AI Agent

This agent uses RFC connections to pull data from FI tables directly. The core data comes from BSID (open customer line items) and BSAD (cleared items for payment history):

def get_ar_aging_data(conn, company_codes):
    # Pull AR data equivalent to FBL5N open items
    open_items = []
    for bukrs in company_codes:
        result = conn.call('RFC_READ_TABLE',
            QUERY_TABLE='BSID',
            DELIMITER='|',
            OPTIONS=[{'TEXT': f"BUKRS = '{bukrs}'"}],
            FIELDS=[
                {'FIELDNAME': 'BUKRS'}, {'FIELDNAME': 'KUNNR'},
                {'FIELDNAME': 'BELNR'}, {'FIELDNAME': 'BUZEI'},
                {'FIELDNAME': 'BLDAT'}, {'FIELDNAME': 'BUDAT'},
                {'FIELDNAME': 'ZFBDT'}, {'FIELDNAME': 'ZBD1T'},
                {'FIELDNAME': 'DMBTR'}, {'FIELDNAME': 'WAERS'},
                {'FIELDNAME': 'SGTXT'}
            ]
        )
        for row in result['DATA']:
            fields = row['WA'].split('|')
            # Parse and append...
            open_items.append(parse_bsid_row(fields, bukrs))
    return pd.DataFrame(open_items)

The AI component here does two things that the manual process couldn't:

1. Payment prediction. Using historical payment data from BSAD, the model predicts when each open item will actually be paid. Not just "it's 45 days past due" but "based on this customer's behavior pattern, this item has a 78% chance of being paid within the next 7 days." This transforms the aging report from a backward-looking snapshot into a forward-looking projection.

from sklearn.ensemble import GradientBoostingClassifier
import numpy as np

def train_payment_predictor(historical_data):
    # Train model on cleared items to predict payment timing
    features = historical_data[[
        'customer_segment', 'invoice_amount_bucket',
        'historical_avg_days_late', 'historical_payment_count',
        'days_since_due', 'company_code', 'is_government',
        'has_payment_plan', 'credit_limit_utilization'
    ]]

    # Target: will pay within 7 days (1) or not (0)
    target = (historical_data['actual_days_to_payment'] <= 7).astype(int)

    model = GradientBoostingClassifier(
        n_estimators=200,
        max_depth=5,
        learning_rate=0.1
    )
    model.fit(features, target)
    return model

2. Intelligent escalation routing. Instead of rigid bracket-based rules, the agent considers the full context. A €50,000 invoice from a customer who always pays 5 days late is not the same risk as a €50,000 invoice from a customer with deteriorating payment patterns. The AI scores each item and routes escalation emails to the right person with the right context.

The agent generates individualized reports for each regional controller, showing only their customers. Sales reps get a morning email with their specific follow-up items, including suggested talking points based on the customer's payment history. "Customer XYZ has 3 invoices totaling €127,000 past 45 days. Their average payment delay has increased from 12 to 28 days over the past quarter — suggest discussing payment terms at next meeting."

ROI for Report #2

The DSO reduction alone justified the entire project ten times over. When you can predict which customers are about to go delinquent before they actually miss the deadline, your collections team can make proactive calls instead of reactive ones. The 8-day DSO improvement on €40M in annual revenue translates to nearly €900K in freed working capital — money that was previously sitting in unpaid invoices.

Report #3: Procurement Compliance Check (ME2M + ME33K)

The Manual Process

This was the most painful one. The compliance analyst would pull all purchase orders created in the past month from ME2M, then manually check each one against the relevant contract in ME33K to verify that the PO price matched the negotiated contract price. For materials without contracts, she'd check against the info record price in ME13.

The checking logic was surprisingly complex:

• Price tolerance: PO price can be up to 3% above contract price for materials, 5% for services
• Quantity tolerance: PO quantity must be within the contract validity period and below remaining contract quantity
• Vendor match: PO vendor must match the contract vendor (obvious, but violations happen when someone manually types a different vendor number)
• Payment terms: PO payment terms must match or be more favorable than contract terms
• Maverick spending: POs for materials that have an active contract but were ordered outside the contract (different vendor or no contract reference)

She'd compile all violations into a spreadsheet, categorize them by severity and department, and send it to the Head of Procurement monthly. The report also fed into the quarterly internal audit.

Total time: approximately 8 hours per week (heavily front-loaded at month-end).

The AI Agent

This agent pulls data from several SAP tables: EKKO/EKPO (PO header/item), EKKO (contract header via document category "K"), EINE/EINA (purchasing info records), and LFA1 (vendor master).

def check_procurement_compliance(conn, company_code, date_from, date_to):
    # Check POs against contracts and info records

    # Get all POs in date range
    po_data = get_purchase_orders(conn, company_code, date_from, date_to)

    # Get all active contracts
    contracts = get_active_contracts(conn, company_code)

    # Get info records for fallback pricing
    info_records = get_info_records(conn)

    violations = []
    for _, po in po_data.iterrows():
        # Find matching contract
        contract = find_matching_contract(
            contracts,
            material=po['material'],
            vendor=po['vendor'],
            plant=po['plant'],
            date=po['doc_date']
        )

        if contract is not None:
            # Check price compliance
            price_deviation = (po['net_price'] - contract['contract_price']) / contract['contract_price']
            tolerance = 0.05 if po['item_category'] == 'D' else 0.03  # services vs materials

            if price_deviation > tolerance:
                violations.append({
                    'type': 'PRICE_OVERRUN',
                    'severity': 'HIGH' if price_deviation > 0.10 else 'MEDIUM',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'po_price': po['net_price'],
                    'contract_price': contract['contract_price'],
                    'deviation_pct': price_deviation * 100,
                    'financial_impact': (po['net_price'] - contract['contract_price']) * po['quantity']
                })

            # Check quantity against remaining contract quantity
            if po['quantity'] > contract['remaining_qty']:
                violations.append({
                    'type': 'QUANTITY_EXCEED',
                    'severity': 'MEDIUM',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'po_qty': po['quantity'],
                    'remaining_contract_qty': contract['remaining_qty']
                })

        else:
            # No contract found — check for maverick spending
            available_contract = find_any_contract_for_material(
                contracts, material=po['material']
            )
            if available_contract is not None:
                violations.append({
                    'type': 'MAVERICK_SPEND',
                    'severity': 'HIGH',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'vendor_used': po['vendor'],
                    'contract_vendor': available_contract['vendor'],
                    'contract_number': available_contract['contract_number'],
                    'financial_impact': po['net_price'] * po['quantity']
                })

    return pd.DataFrame(violations)

The AI adds value here in three ways:

1. Pattern detection for systematic compliance issues. The model identifies patterns that suggest organizational problems, not just individual violations. "Department 4200 has had 23 maverick spend instances in the past 90 days, all from the same buyer. 18 of them are for materials covered by contract 4600012345 with vendor 100234." This is not something you'd catch by reviewing individual POs.

2. False positive reduction. Many apparent violations have legitimate reasons — emergency purchases, contract amendments not yet reflected in the system, vendor substitutions approved by procurement management. The AI model learns from historical disposition data (which violations were marked as "justified" in previous audits) and assigns a confidence score. Violations that match patterns of historically justified exceptions are deprioritized, saving the compliance team from reviewing hundreds of non-issues.

3. Financial impact forecasting. Instead of just showing "this PO is 7% above contract price," the agent calculates the total annual impact if this pricing deviation persists across all orders for this material. A 7% overrun on a material you order twice a year is €200. The same overrun on a material you order weekly could be €50,000 annually.

def calculate_annualized_impact(violation, historical_orders):
    # Project annual financial impact of a compliance violation
    material = violation['material']
    vendor = violation['vendor_used'] if 'vendor_used' in violation else violation.get('vendor')

    # Get order frequency for this material
    mat_orders = historical_orders[
        (historical_orders['material'] == material) &
        (historical_orders['doc_date'] >= pd.Timestamp.now() - pd.Timedelta(days=365))
    ]

    annual_quantity = mat_orders['quantity'].sum()
    order_frequency = len(mat_orders)

    if violation['type'] == 'PRICE_OVERRUN':
        unit_overrun = violation['po_price'] - violation['contract_price']
        annualized = unit_overrun * annual_quantity
    elif violation['type'] == 'MAVERICK_SPEND':
        # Estimate savings if contract had been used
        annualized = violation['financial_impact'] * (order_frequency / max(len(mat_orders), 1))
    else:
        annualized = 0

    return {
        'annual_quantity': annual_quantity,
        'order_frequency': order_frequency,
        'annualized_financial_impact': annualized
    }

ROI for Report #3

The recovery rate jumped from 15% to 40% because the AI agent presents each violation with full context — the contract details, the historical pattern, the annualized impact, and a recommended action. When a procurement manager receives a report saying "Buyer X has placed €890,000 in orders outside contracts over the past quarter, here are the top 5 patterns and suggested corrections," they can take immediate action instead of spending days investigating.

The Technical Infrastructure Behind All Three Agents

All three agents share common infrastructure:

• Runtime: Python 3.11 on an Ubuntu VM with 4 cores and 8 GB RAM
• SAP connectivity: PyRFC with SAP NetWeaver RFC SDK, connecting via a dedicated RFC user with minimal authorizations (read-only access to the specific tables and BAPIs needed)
• Scheduling: APScheduler with a PostgreSQL job store for persistence
• ML framework: scikit-learn for the classification and prediction models, retrained monthly from fresh SAP data
• Report generation: Jinja2 templates producing HTML emails, with pandas for data manipulation
• Monitoring: Prometheus metrics exported to Grafana — execution time, record counts, error rates

The total infrastructure cost across all three agents is approximately €6,000 per year. The combined annual benefit is over €1.5 million. That's a 250x return.

What I Learned Building These

Start with the report your team hates most. Don't pick the easiest one — pick the one that causes the most frustration. That's where you'll get the fastest adoption and the least resistance from stakeholders. Nobody argued with automating the compliance report because everyone hated producing it and receiving it late.

The AI isn't the hard part — the data extraction is. Getting data out of SAP reliably, handling the quirks of RFC_READ_TABLE (65,535 row limit per call, anyone?), dealing with currency conversion, fiscal year differences, and SAP's unique date formats — that's where 70% of the development time goes. The actual ML models are straightforward classification and regression problems.

Keep the human in the loop, but move them from "producer" to "reviewer." None of these agents run completely autonomously. Each one produces a report that a human reviews before distribution. But reviewing a finished, contextualized report takes 15-30 minutes. Producing it from scratch took 6-8 hours. That's the efficiency gain.

RFC is better than OData for batch operations. I initially tried using OData APIs for everything. For the stock coverage report, pulling 14 plants worth of stock data through OData took 12 minutes and frequently timed out. The same data through RFC takes 45 seconds. OData is great for transactional operations and UI integration, but for batch analytics, RFC is simply faster.

Build the feedback loop from day one. Each agent has a simple mechanism for users to flag issues — a "report problem" link in the email that creates a ticket. This feedback feeds back into model retraining. The AR aging model improved its payment prediction accuracy from 71% to 89% over six months purely from user corrections.

The Combined Numbers

An 11-day payback period. That's not a typo. The financial benefits from reduced stock-outs, improved DSO, and recovered maverick spend dwarf both the development and ongoing costs.

Should You Do This?

If your team spends more than 4 hours per week on any recurring SAP report that involves exporting data, manipulating it in Excel, and distributing results, the answer is yes. The pattern is always the same: extract via RFC, analyze with Python (with or without ML depending on the complexity), format with templates, distribute via email or Teams, monitor with standard tools.

The three reports I chose aren't special. The same approach works for MRP exception analysis (MD04), production order variance reports (CO03), quality inspection results (QA32), transport management reports (VT02N), and dozens of other recurring SAP reports that are currently produced manually.

Stop exporting to Excel. Build an agent. Measure the results. The ROI will speak for itself.