A business may have years of sales, invoices and supplier records yet still struggle to answer a practical question: which orders are most likely to arrive late next month?
At SAP TechEd on October 27, 2026, SAP announced an expansion of its SAP-RPT family of models for structured business data. The updates cover forecasting, decision support and planned capabilities for analysing related tables and detecting unusual records.
The useful question for businesses is how these models could turn existing records into better predictions—and whether those predictions improve a real decision.
What SAP announced, and when it will be available
According to SAP’s TechEd innovation guide, the models have different release schedules:
| Model | Announced purpose | Availability stated by SAP |
|---|---|---|
| SAP-RPT-TS | Forecasting values over time, including demand planning | Generally available now |
| SAP-RPT-Decisions | Supporting decisions within applications and agent workflows | General availability planned for Q4 2026 |
| SAP-RPT-2 | Native multi-table processing, anomaly detection and structured-data embeddings | General availability planned for Q1 2027 |
The distinction matters for project planning. A team evaluating forecasting today has a different starting point from one waiting for the new multi-table capabilities. The planned dates are SAP’s roadmap commitments, rather than evidence that every announced feature is already accessible.
What is a tabular foundation model?
Tabular data is information arranged in rows and columns: a row for each invoice, for example, with columns for its amount, customer, due date and payment status.
SAP describes SAP-RPT as a pretrained model designed for this kind of information. It uses in-context learning: examples supplied with a request provide the context for a prediction, without a separate training cycle for each task.
Imagine providing historical invoices with known payment delays, alongside newer invoices whose payment dates are unknown. A prediction task could estimate the likely delay for each new invoice. That is an illustrative use case, rather than a claim about a measured result from the new releases.
The distinction between common prediction tasks is straightforward. Classification assigns a category, such as a risk group. Regression estimates a number, such as days late. Forecasting estimates how a value may evolve over time.
SAP’s product overview explains the table-oriented approach, while its existing RPT-1 tutorial demonstrates classification and regression. That tutorial describes the earlier model; its limits should not automatically be applied to the newly announced versions.
Why relationships between tables matter
Consider a hypothetical distributor trying to anticipate delayed deliveries. Its order table records requested delivery dates. Another table tracks supplier performance. A third records warehouse receipts.
A useful prediction might depend on connecting all three. A supplier’s average delay alone could hide a problem affecting one product range or warehouse.
SAP positions the planned multi-table capabilities as a way to reduce manual engineering around such relationships. The practical value would depend on whether the model can use those connections reliably in the customer’s own environment.
Even with that capability, someone must establish what each field means. An “arrival date” might refer to a planned delivery, a physical receipt or the moment an employee entered the receipt into the system. Mixing those definitions can make an apparently precise prediction answer the wrong question.
How predictive models could work with AI assistants
A possible workflow would combine several components: a predictive model estimates demand, an assistant explains the result, and a business application presents a proposed purchasing decision.
This is an architectural example, not a description of a deployment tested by DemystIA. It illustrates why the prediction, explanation and action each need a clear role.
A readable explanation does not establish forecast accuracy. Likewise, an accurate forecast does not decide how much inventory a company should buy. That decision also depends on margins, storage capacity, supplier terms and the cost of running short.
Readers considering the action stage can explore our guide to what businesses can delegate to AI agents.
What a useful pilot should measure
For a first evaluation, choose one decision with a measurable outcome. Demand planning for a defined product group is easier to assess than a project promising to improve forecasting across the entire business.
A practical test should:
- Use a credible baseline. Compare the model with the current process, including a simple forecasting method where appropriate.
- Respect the timeline. Predict historical outcomes using only information that would have been available at the time.
- Measure the cost of errors. Underestimating demand and overestimating it can have very different consequences.
- Include operating effort. Account for data access, integration, monitoring and review alongside model usage.
These are evaluation recommendations. SAP’s announcements do not establish that a particular customer will achieve better results or lower costs.
Review capacity also deserves attention. Flagging thousands of unusual transactions can create a queue that people cannot investigate. Our article on the human attention bottleneck explores that operational problem.
What this means for business AI
DemystIA’s reading of the announcement is that specialised prediction models deserve a place in enterprise AI evaluations alongside conversational tools. For companies with substantial operational data, a useful application may begin with a clearly defined forecasting or classification problem.
SAP’s roadmap creates opportunities to test that approach. The strongest evidence will come from customer evaluations that show better decisions, manageable integration costs and reliable performance as business conditions change.