SAP Spent a Billion Euros on Spreadsheets. It Might Be the Smartest AI Bet of the Year
SAP closed its Prior Labs deal in July with over a billion euros behind tabular foundation models. The boring data was always where the value sat.
On 17 July 2026, SAP completed its acquisition of Prior Labs, committing over a billion euros to scale the Freiburg startup into a frontier AI lab focused on structured business data. Not chatbots. Not agents. Tables.
Prior Labs built TabPFN, a series of tabular foundation models published in Nature, which has topped tabular benchmarks across a large body of independent academic work. The latest generation, TabPFN-2.5, handles datasets up to roughly 50,000 rows and 2,000 features and leads the TabArena benchmark, outperforming tuned tree-based models and matching AutoGluon-class accuracy. Prior Labs keeps its brand, its Freiburg headquarters, its open-source commitments, and an advisory board including Yann LeCun and Bernhard Schölkopf.
The strategic read is straightforward and, I think, correct: the largest untapped pool of enterprise AI value is not in documents or conversations. It is in the ERP tables, operational databases and spreadsheets that already run the business.
Why tabular data stayed stubbornly un-disrupted#
Every other modality got a foundation model moment. Text in 2020, images shortly after, audio and video since. Tabular data — which is most enterprise data by volume of decisions made on it — sat out the whole thing.
For good reason. Transfer learning was the mechanism that made foundation models work, and tabular data appeared to have nothing to transfer. Your customer churn table and my equipment failure table share no columns, no semantics, no structure. There is no equivalent of “language” underneath them.
So the state of the art stayed where it had been for a decade: gradient-boosted decision trees. XGBoost, LightGBM, CatBoost. Excellent models, genuinely hard to beat, and still winning Kaggle competitions long after deep learning had swept every other domain.
The insight behind TabPFN is that what transfers is not the data but the inference procedure. Train a transformer on enormous numbers of synthetic tabular problems generated from structural priors, and it learns to do Bayesian inference over tabular relationships in general. At prediction time it does not fit parameters to your dataset — it conditions on your dataset in a forward pass and predicts. In-context learning, applied to tables.
What this changes in practice#
The headline is not accuracy. On large datasets, well-tuned gradient boosting remains highly competitive, and anyone claiming otherwise is selling something.
The change is time-to-model and behaviour on small data, and both matter more in enterprise settings than benchmark accuracy does.
Small datasets get dramatically better. The default enterprise ML problem is not a million rows. It is 800 rows, because that is how many equipment failures actually happened, or how many patients had that specific complication, or how many students left mid-year. Gradient boosting on 800 rows requires careful regularisation and cross-validation discipline to avoid overfitting, and most teams get it wrong. This is precisely where an in-context approach with strong priors shows its largest margin.
No hyperparameter search. A significant share of the effort in a tabular ML project is tuning. Removing it changes the economics of building a model for a narrow question — which means you build models for questions that previously were not worth a two-week project.
Faster iteration on features. When fitting takes seconds rather than an afternoon, testing whether a new feature helps stops being a scheduling decision.
The constraints are real and should be respected: roughly 50,000 rows and 2,000 features is the current envelope. If you have ten million rows, this is not your tool. That envelope is not a limitation for most enterprise questions, which is the whole point.
When I would use which#
Practical guidance for teams deciding:
Reach for a tabular foundation model when your dataset is under about 50,000 rows, you need a strong baseline quickly, the problem is genuinely tabular (numeric and categorical columns, one prediction target), and you do not have weeks of tuning available.
Stay with gradient boosting when your data is large, you need a model artefact you fully control and can deploy anywhere at fixed cost, you require detailed feature importance for a regulated explanation, or your inference latency budget is tight and predictable.
Do neither when the honest answer is a SQL query. This remains, by a distance, the most common finding in our discovery work. A large share of “we need ML for this” turns out to be a well-specified aggregate over data nobody had joined yet.
The ERP angle, which is the actual story#
SAP did not buy this for the research. They bought it because their customers’ most valuable data has been sitting inside SAP tables for thirty years, mostly unmodelled.
That is the reality of every ERP, ours included. The system faithfully records every purchase order, every stock movement, every invoice, every service event — and then produces reports about them. The predictive layer that would make the data operational either does not exist or lives in a data science team’s notebook, disconnected from the transaction system where someone might act on it.
This is precisely the argument we make for treating ERP as a data platform with a thoughtful interface on top, rather than as a system of record with a reporting bolt-on.
In a Hospital Management System, the tabular questions are everywhere and almost all of them are small-data: which scheduled admissions will not arrive, which claims will be denied and why, which theatre lists will overrun, which patients will readmit within 30 days. Every one of those has a few thousand historical examples and a clear target column. Every one of those is currently a nurse’s intuition and a spreadsheet.
In a School ERP, the same pattern: which enrolled students will not return next term, which fee accounts will fall into arrears, which cohorts are drifting on assessment. Hundreds to low thousands of rows, high-value predictions, no dedicated data science team anywhere in the building.
The reason those models do not exist is not that the algorithms were unavailable. It is that each one required a project, and no individual question justified one. Collapsing the cost of building a narrow tabular model is what makes the long tail of them viable — and the long tail is where the operational value has been sitting the whole time.
The unglamorous prerequisite#
None of this rescues you from data quality. A tabular foundation model conditions on the rows you give it; if your entity resolution is broken and the same customer appears three times with different identifiers, you get a confident model of a fiction.
The prerequisite list has not changed: consistent identifiers, documented column semantics, known freshness, and a target definition that domain experts agree on. Get those and the modelling step is now genuinely cheap. Skip them and the modelling step being cheap just means you produce wrong answers faster.
The highest-value AI in most organisations is a small model over clean ERP tables, not a chatbot. That is our default recommendation and it is usually right. Show us your tables.