Back to Blog
AI

Most Company Data Is Tables: Why Classical ML Beats LLMs for ERP Data Prediction

For tabular ERP data like sales, inventory, and customer records, classical ML such as gradient boosting beats LLMs on cost, accuracy, and reproducibility. This guide covers the practical side: feature engineering, preventing data leakage, SHAP explanations, and a hybrid setup where ML and LLMs each do their own job.

POLYGLOTSOFT Tech Team2026-09-157 min read2
Tabular DataMachine LearningGradient BoostingERP DataPredictive Modeling

The Myth That "Adopting AI" Means "Adopting an LLM"

When companies start exploring AI, most of them think of a chat-style LLM first. Yet the predictions that actually drive business decisions come from the data inside the ERP. Sales slips, inventory movements, customer ledgers, and equipment logs are all structured data made of rows and columns.

Paste those tables into an LLM and ask it to "flag the customers likely to pay late next month," and you run into three problems:

  • Cost: Turning hundreds of thousands of rows into tokens makes every prediction expensive, and you hit context limits quickly
  • Accuracy: LLMs don't reliably learn nonlinear relationships or thresholds between numeric values
  • Reproducibility: The same input can produce different answers, which makes audits and validation difficult
  • Models Built for Tabular Data

    Why gradient boosting is still the standard

    Gradient boosting libraries such as XGBoost, LightGBM, and CatBoost have been the go-to choice for tabular prediction for years. The 2022 NeurIPS paper "Why do tree-based models still outperform deep learning on tabular data?" found that tree-based models beat deep learning on medium-sized tabular datasets. They handle missing values and categorical variables well, and they can train on millions of rows in minutes on an ordinary CPU server.

    Foundation models for tables

    Foundation models built specifically for tables, such as TabPFN, have appeared more recently. On small datasets of a few thousand to about 10,000 rows, they perform well with no tuning at all. For large transaction histories or real-time production systems, though, proven deployments are still limited. For now, the practical move is to use them as a baseline to compare against on smaller datasets.

    Prediction Use Cases You Can Start Today

  • Customer churn and late-payment prediction: Spot at-risk accounts early from trends in payment delays and declining order frequency
  • Delivery delay prediction: Factor in production load, material arrival variance, and supplier history
  • Order quantity and safety stock: Combine demand forecasts with the distribution of forecast errors to balance stockouts against holding costs
  • Quote win probability: Rank sales opportunities by discount rate, past relationship, and competitive bidding
  • Features and Leakage Make or Break the Project

    Domain-driven feature engineering

    Performance depends heavily on turning the judgment calls your staff already make into numbers. That means features like "this month's payment delay compared with the 3-month average" or "days since the last purchase order" rather than raw columns.

    Data leakage and time-based splits

    The most common way these projects fail is data leakage. If a late-payment model includes the "collections referral date," it may score 95% in validation and still be useless in production, because that information doesn't exist at the moment you make the prediction. Validation data shouldn't be split at random either. Use a chronological split, such as "train through 2025, validate on the first half of 2026," to get an honest estimate of real-world performance.

    Explainability Drives Adoption

    A model that only says "late-payment risk: 0.82" is easy for staff to ignore. If they can't see why, they won't trust the score and won't know what to do about it. With SHAP, you can show the reasons behind each prediction, for example "rising payment delays contributed +0.21 and falling order volume +0.15." A model becomes part of daily work when its reasoning matches what experienced staff already sense.

    A Hybrid Architecture: ML and LLMs, Each in Its Place

    The realistic answer isn't choosing one or the other. It's giving each its own job.

  • ML: Numeric forecasts, risk scores, and SHAP explanations
  • LLM: Turning predictions and their drivers into plain language, drafting weekly reports, and answering questions like "Which customers are most at risk of paying late this month?"
  • When the LLM delivers the ML results instead of producing numbers itself, you cut both cost and the risk of hallucination.

    Predicting From Your ERP Data With POLYGLOTSOFT

    POLYGLOTSOFT delivers the full pipeline on top of your ERP, MES, and WMS data: defining the prediction task, checking for leakage and validating on time-based splits, building gradient boosting models, explaining results with SHAP, and connecting LLM-generated reports. Our experience on smart factory and logistics sites helps us design features your teams will actually use. If you're curious what your own data could predict, we'd be glad to hear from you.

    Need Technical Consultation?

    Our expert consultants in smart factory, AI, and logistics automation will analyze your requirements.

    Request Free Consultation