The Capital Twin, Empowered: How SAP-RPT's Table-Native AI Delivers Structural Superiority in Capital Optimization

. Enterprise AI must move beyond language Large language models have made conversational interfaces, document analysis, knowledge retrieval, and code generation widely accessible. They can interpret instructions, summarize complex information, explain business processes, and coordinate tasks across applications. Their contribution is substantial, but they do not, by themselves, resolve the central enterprise challenge: converting fragmented operational and financial data into reliable predictions and economically meaningful decisions. A company does not run on language alone. It runs on interdependent objects, transactions, quantities, prices, dates, currencies, statuses, counterparties, hierarchies, and business rules. A purchase order connects a supplier, material, plant, delivery schedule, contract, goods receipt, invoice, and eventual payment. A production order connects components, operations, work centers, confirmations, quality results, and costs. A receivable has a due date, payment history, dispute status, currency exposure, and expected cash-conversion date. The meaning of each record depends on its relationships with others. Language fluency is not relational integrity, numerical prediction, or knowledge of a company's current operating state. An LLM (Large Language Model) can generate a database query, but the database engine must still execute it, enforce the schema, apply permissions, and return the records. The model's ability to describe a join does not prove that the join is semantically correct. Similar identifiers may refer to different objects; a delivery status may be preliminary rather than legally significant; a quantity may be expressed in pieces rather than cases; and a financial value may be in local rather than group currency. These are questions of data semantics and process context. Prediction introduces another distinction. Enterprise decisions often require estimating outcomes from structured variables: whether a customer may pay late, a supplier may fail to deliver, inventory may become obsolete, a transaction is anomalous, or demand may change. A fluent explanation is not a validated prediction. Numerical consistency, probability calibration, repeatability, and performance on the relevant business population must be tested. LLMs also lack automatic access to a company's current SAP state. Retrieval and tool integration can supply current records, but those connections must be designed, secured, monitored, and governed. A large context window is not a substitute for a controlled business data model. None of this makes LLMs unsuitable for enterprise AI. They are well suited to the conversational layer: helping users investigate exceptions, interpret predictions, retrieve contractual evidence, explain model outputs, and initiate approved workflows. They can make complex information accessible and coordinate calls to authorized services. The question is not whether LLMs can be connected to databases. They can. The question is whether language generation alone should be responsible for predicting complex business outcomes and assessing financial exposures. For those tasks, purpose-built predictive models and governed data structures are essential. II. SAP RPT (Relational Pretrained Transformer): Predictive Intelligence for Structured Business Data SAP's Relational Pre-trained Transformer takes a different approach. Rather than treating enterprise tables as text that must be translated into a language sequence, RPT is designed to work with structured and relational business data. It is a table-native foundation model for predictive tasks such as classification and regression. Through in-context learning, it can use relevant examples and records supplied at inference time to generate predictions without requiring a separate training cycle for every use case. This is relevant in enterprises where many prediction problems exist, but each individual use case may not justify a dedicated machine-learning pipeline. RPT works with the types of data that populate enterprise applications: rows, columns, numerical values, categories, identifiers, and relationships represented in structured datasets. A pretrained model can potentially address multiple problems through appropriate context selection, validation, and orchestration, reducing the need to maintain a different predictive model for every supplier, material, customer, plant, or process. A table-native model does not automatically resolve every data-quality problem, define the meaning of every field, or guarantee every prediction. Organizations must still select relevant data, define target variables, understand the population being evaluated, prevent data leakage, test calibration, and monitor performance as conditions change. RPT reduces the need to build predictive models from scratch; it does not eliminate data governance, business semantics, validation, or model-risk management. The SAP-RPT family is expanding rapidly. Originally introduced as SAP-RPT-1 in Q4 2025, the tabular foundation model has evolved through SAP-RPT-1.5, released in July 2026, and SAP-RPT-1.6, released in September 2026. As of November 2026, SAP-RPT-1.6 is SAP's latest generally available version for tabular classification and regression, accessible through the SAP AI Core generative AI hub and its model library. It introduces enhanced prediction quality, explainability, and Deep Context Mode in its large variant, extending its capabilities for complex enterprise prediction scenarios. SAP-RPT-TS extends the family beyond static tabular data into time-series forecasting, supporting business applications such as demand and operational forecasting through SAP HANA Cloud and SAP AI Core; it is already generally available. SAP has also announced SAP-RPT-Decisions, designed to support decision intelligence across business applications and agentic workflows, with general availability planned for Q4 2026. Looking further ahead, SAP-RPT-2 is planned to extend SAP-RPT-1.6 with native multi-table processing, anomaly and outlier detection, and structured data embeddings, with general availability planned for Q1 2027. These announcements represent an important evolution of SAP's predictive AI capabilities, while maintaining a clear distinction between models already generally available and capabilities still on SAP's product roadmap. The multi-table direction is especially relevant to Capital Twin. Supplier risk may depend on purchase orders, delivery performance, quality notifications, invoice disputes, payment history, alternative sourcing, inventory coverage, and the criticality of supplied materials. Customer exposure may depend on limits, orders, deliveries, receivables, payment behavior, disputes, currencies, and contract terms. Native multi-table processing has the potential to reduce manual preparation when related business information is brought together for prediction. RPT is therefore a specialized predictive layer, complementing LLMs, statistical models, and deterministic services. LLMs and SAP-RPT are complementary by data modality: LLMs handle open-ended language—reasoning, synthesis, and conversational intent—while RPT is table-native, consuming structured business rows and columns via in-context learning without per-use-case training. SAP positions tabular models explicitly as a complement to LLMs because LLMs incur higher inference cost and lower accuracy on numbers and dates, whereas RPT delivers “zero-training” predictions directly on ERP records. In practice, data products can anchor the LLM with trusted organizational context while simultaneously feeding SAP-RPT the contextual information it needs to improve tabular prediction accuracy. SAP-RPT: The Product of Five Decades of Enterprise Data Harmonization SAP did not introduce SAP-RPT as the result of a sudden insight or an isolated two-year development initiative. The model itself is a recent technological achievement, but the foundation that makes it strategically significant is the result of more than five decades of continuous evolution. Since its foundation in 1972, SAP has pursued the integration and real-time processing of business processes, progressively encoding an extraordinary depth of operational knowledge into standardized applications, structured data models, relational structures, and business semantics. Over five decades, this has created an extensive foundation in which business entities such as suppliers, customers, materials, orders, contracts, production operations, deliveries, invoices, and payments are connected through meaningful relationships and integrated business processes. This is precisely the environment for which SAP-RPT was designed: bringing predictive intelligence to structured, relational enterprise data by leveraging the patterns and relationships that conventional language-based models are not inherently optimized to process. The Banking Data Fragmentation Barrier: Why LLMs Cannot Replace Relational Foundations The contrast with much of the traditional banking technology landscape is particularly relevant. Banking architectures have historically evolved around separate core systems for payments, lending, treasury, risk management, customer information, and financial products. These systems often maintain their own data structures, identifiers, definitions, and processing logic. Even when information is consolidated into enterprise data warehouses or data lakes, physical aggregation does not automatically establish referential integrity, consistent business semantics, harmonized master data, or reliable relationships across the underlying transactions. Consequently, the absence of a coherent relational foundation can severely constrain the ability to exploit SAP-RPT across interconnected banking processes. This does not make RPT unusable in banking: properly structured and governed datasets can still support its predictive capabilities. However, without consistent relationships between customers, contracts, transactions, exposures, collateral, payments, and financial outcomes, much of the potential advantage of a relational foundation model remains inaccessible. This fragmentation also explains the appeal of LLM-based solutions for many banking applications, particularly where information must be extracted from documents, interpreted across heterogeneous sources, or accessed through natural-language interfaces. Yet LLMs cannot independently reconstruct missing referential integrity, guarantee semantic consistency, or replace specialized predictive models for structured financial data. They can orchestrate access to information, but they do not eliminate the underlying data architecture problem. As long as banking systems remain structured in silos, their ability to exploit artificial intelligence will be fundamentally constrained. Without an integrated relational data foundation connecting customers, contracts, transactions, payments, exposures, collateral, and financial outcomes, banks will remain heavily dependent on LLM-based approaches to navigate fragmented information, rather than fully leveraging the predictive capabilities of specialized AI models designed to operate on structured and interconnected data. This fragmentation will significantly hinder their ability to unlock the full potential of artificial intelligence, particularly in areas such as predictive risk management, financial decision-making, operational optimization, and capital allocation. Clean Core: From Five Decades of Integration to the Autonomous Enterprise The Clean Core strategy extends SAP's historical direction by reinforcing process standardization, stable integrations, data governance, and consistent business semantics, reducing the fragmentation and technical debt that undermine enterprise intelligence. This is also a fundamental prerequisite for SAP's Autonomous Enterprise vision, where AI agents must operate on trusted business data and understand the relationships, constraints, and consequences embedded in real-world processes. The significance of SAP-RPT, therefore, cannot be understood simply by looking at the period in which the model was developed. Its strategic foundation represents more than 50 years of accumulated enterprise knowledge, process integration, and data harmonization. SAP has not spent two years preparing the ground for RPT; it has spent more than five decades building the enterprise foundation that makes this generation of predictive AI possible. III. The Capital Twin: From Operational Evidence to Financial Meaning The Capital Twin is the architectural layer that connects operational reality with financial interpretation and capital-market logic. It is not another ERP system or accounting ledger, and it does not imply that every operational event automatically becomes a financial instrument. It is a forward-looking representation of the economic utility, liquidity impact, risk, and financing potential of assets and commitments across an enterprise and its business network. Three forms of representation need to be distinguished. The Digital Twin describes the physical or operational state of an asset or process: where a shipment is, how a machine is performing, whether a production line is available, or what condition a container is in. The Financial Twin describes the accounting state: what has been recognized, valued, accrued, invoiced, paid, or posted. In SAP S/4HANA, the Universal Journal and ACDOCA provide an important foundation for the integrated financial and controlling view. The Capital Twin extends both perspectives by asking what an asset or commitment means for future liquidity, risk, financing, and capital allocation. Inventory, for example, is not economically defined only by its material number and book value. Its capital relevance depends on location, ownership, whether it is pledged or saleable, whether it is needed for confirmed production, how quickly it can be converted into cash, and what risks could impair its value. The same stock can be essential to production continuity, excessive from a working-capital perspective, eligible or ineligible for secured financing, and exposed to price, quality, or obsolescence risk. The same principle applies to work in progress, purchase commitments, confirmed sales orders, receivables, and goods in transit. A purchase order may create a future cash requirement and a dependency on supplier performance. A customer order may create expected revenue but also require capacity, components, and logistics. A shipment may support financing only if ownership, transfer of risk, insurance, documentary evidence, and legal rights are adequately established. Capital Twin connects these facts with forecasts and risk assessments so the enterprise can understand what it can responsibly mobilize, finance, hedge, or optimize. SAP and RPT provide operational data and predictive signals; Capital Twin gives those signals economic meaning. It identifies which events affect liquidity, which exposures require risk assessment, which assets may qualify for financing under defined rules, and which commitments consume financial capacity before cash moves. It distinguishes accounting value from realizable value, forecast from contractual obligation, and operational status from legally enforceable evidence. IV. The Real Economy: SAP and RPT as a Predictive Operating Foundation The first layer is the real economy. SAP systems support processes through which companies create, transform, move, sell, and service goods and services. SAP S/4HANA provides the transactional core. SAP Ariba and SAP Business Network support procurement and supplier collaboration. SAP Integrated Business Planning supports demand, supply, and inventory planning. Manufacturing, warehouse, asset-management, transportation, and logistics applications capture execution. APIs, IDocs, EDI, event-driven integration, and business-network capabilities connect these processes with suppliers, customers, carriers, and other partners. The value of this landscape is not simply the quantity of data it contains. Business events are generated through structured processes with identifiable objects and relationships. A purchase order is linked to a supplier, material, plant, schedule, and account assignment. A production order is linked to components, operations, work centers, confirmations, and cost information. A delivery is linked to a customer, route, shipment, quantity, and proof-of-delivery process. When governed and semantically aligned, these records provide a detailed representation of economic activity across the value chain. RPT can add predictive intelligence to this foundation. Supplier performance data can support risk classification and identify delivery patterns that deserve attention. Payment histories and receivable characteristics can support payment-delay prediction. Inventory and demand information can help identify excess, shortage, or obsolescence risks. Time-series models can forecast demand, sales, and operational metrics. Anomaly detection can help identify unusual transaction patterns as the relevant capabilities become available. Each use case must be validated against actual data and outcomes. Consider a manufacturer dependent on a small group of suppliers for critical components. A conventional procurement view may show purchase prices, open quantities, and requested delivery dates. A predictive view can incorporate delivery reliability, quality performance, confirmation behavior, capacity signals, lead-time variability, and alternative sourcing. It can identify where production continuity, inventory policy, working capital, and customer commitments may be affected. Capital Twin then translates the predicted operational consequence into liquidity and capital implications. The same logic applies to inventory. Predictive intelligence can estimate demand behavior, identify slow-moving positions, anticipate shortages, and assess likely consumption timing. Capital Twin can combine those predictions with ownership, storage, quality, contractual restrictions, and financing rules to distinguish inventory that is economically productive from inventory that ties up cash without sufficient operational or financial benefit. One predictive signal can therefore inform planning, procurement, operations, and treasury rather than remaining isolated in a single function. V. Financial Translation: From Prediction to Capital Intelligence A prediction has limited financial value until it is connected to a decision and an economic consequence. A high supplier-risk score, for example, is not itself a financing cost. It becomes relevant when the enterprise understands which materials depend on that supplier, which production orders may be affected, what inventory buffer is available, what alternative sourcing would cost, and when customer cash flows may be delayed. Capital Twin connects the predictive signal with contractual and operational context, then translates the expected consequences into liquidity, risk, and capital considerations. This translation can support liquidity analysis, credit assessment, collateral evaluation, market-risk management, and capital optimization. Liquidity analysis estimates when cash may be required or received and how operational uncertainty affects timing. Credit analysis considers counterparty strength, behavior, exposure structure, and potential loss. Collateral analysis examines ownership, eligibility, valuation, control, and enforceability. Market-risk analysis considers currency, interest-rate, and commodity exposures arising from purchases, production, sales, and financing commitments. RPT can contribute predictive inputs. It may help classify payment-delay risk, estimate outcomes from structured records, identify patterns associated with supplier or customer deterioration, or forecast operational variables that influence cash conversion. But RPT does not by itself calculate every banking risk measure, determine legal collateral eligibility, recognize an IFRS allowance, or certify a regulatory capital figure. Those outcomes require validated methodologies, definitions, rules, governance, and often deterministic calculation engines. Capital Twin connects predictive signals with those financial methods and controls. This distinction matters when applying banking concepts to the real economy. Metrics such as probability of default, loss given default, exposure at default, and risk-weighted assets belong to defined prudential and credit-risk methodologies. A corporation may use comparable concepts to evaluate counterparty and financing risk, but its internal management estimate is not automatically a regulatory bank calculation. Expected-credit-loss accounting is governed by the applicable accounting standard and cannot be replaced by a generic prediction score. The result is a more complete way to evaluate decisions. A supplier with the lowest unit price may not be the most economical option if poor delivery reliability creates extra inventory, expediting, production disruption, and financing costs. A customer with attractive revenue potential may create an unfavorable exposure if payment behavior, currency terms, and concentration risk are ignored. Inventory may look valuable at book value but be unsuitable as collateral because it is obsolete, restricted, uninsurable, or difficult to liquidate. Capital Twin makes these trade-offs visible before they become expensive surprises. VI. The Financial Economy: SAP Banking and RPT Banks and financing institutions also operate on structured data: customer and counterparty records, financial contracts, payment transactions, collateral positions, limits, exposures, balances, delinquency histories, risk classifications, market variables, and regulatory attributes. These datasets are relational and complex. Their predictive use requires the same discipline as the real-economy layer, but the variables, controls, and regulatory obligations are specific to financial services. SAP banking solutions and finance-and-risk architectures provide an established environment for managing financial products, accounting, risk measurement, and related processes. SAP Bank Analyzer and its associated Integrated Finance and Risk Architecture are examples of banking-oriented capabilities. Capital Twin does not assume that these components automatically consume every operational SAP event or that RPT is already embedded in every banking process. It proposes that banking's structured data foundations can be enriched by RPT-based prediction and connected to operational evidence through properly designed integration, data products, model governance, and application services. Traditional corporate credit assessment may rely on financial statements, bureau data, historical repayment behavior, and periodic reporting. Those sources remain important, but they can be delayed relative to operating events that determine whether a company will generate future cash. Purchase commitments, confirmed orders, production progress, inventory movements, shipment status, customer deliveries, invoice disputes, and collections can provide additional evidence about the activity that supports repayment capacity. Capital Twin can translate this operational evidence into a structured financial representation that a bank can assess within its own credit, risk, product, and compliance frameworks. RPT can then be used on relevant tabular datasets within the financial institution to improve selected predictions, such as payment-delay risk or counterparty behavior. The models and variables need not be identical on both sides: the real and financial economies have different objectives, data rights, labels, and control requirements. Banks retain responsibility for underwriting, pricing, funding, risk limits, and regulatory compliance; Capital Twin improves the information available for those decisions. VII. The Evidence Economy, Contractual Gravity, and Financial Airbnb The Capital Twin depends on the Evidence Economy: financial decisions become more intelligent when supported by traceable evidence generated by real business processes. A purchase order, supplier confirmation, production record, quality inspection, warehouse receipt, transport event, proof of delivery, invoice, collection, and bank statement are not interchangeable documents. Each records a different event, status, and evidential weight. The architecture must preserve who created the record, when it was created, which business object it refers to, whether it has been amended, and what legal or operational meaning can reasonably be assigned to it. The Evidence Economy is not simply about collecting more data. It is about distinguishing intention from commitment, forecast from confirmation, physical event from legal transfer, and accounting entry from underlying economic condition. A shipment tracking update may confirm location but not ownership. A warehouse record may show quantity but not prove that goods are free of liens. A sales order may indicate expected revenue but not establish that revenue can already be recognized. The Capital Twin must retain these distinctions if its financial outputs are to be trusted. This is closely connected to Contractual Gravity. Capital can become economically committed before an invoice or payment appears. A company may reserve production capacity, accept a purchase obligation, allocate inventory to a customer, contract transportation, or enter a foreign-currency purchase commitment. These decisions constrain future liquidity and operational choices. Contractual Gravity describes how binding or commercially significant commitments create economic consequences before those consequences are fully visible in accounting records or cash balances. RPT can help estimate the probability and timing of selected outcomes associated with these commitments, provided relevant structured data and target definitions are available. Capital Twin interprets each commitment in context: whether it is binding, cancellable, conditional, disputed, insured, matched by an incoming receipt, or dependent on an operational milestone. It can distinguish the gross value of a commitment from the portion expected to become a cash requirement and identify where uncertainty has the greatest potential effect on liquidity. Once operational evidence can be translated into financial context, a new financing model becomes possible: the Financial Airbnb. Inspired by platforms that make underused resources visible and connect them with parties that can use them, the concept aims to identify where liquidity is needed, where financial capacity is available, and whether a transaction can be structured around verifiable economic activity or an eligible asset. A supplier may need funding for raw materials, a manufacturer for work in progress, a logistics provider while goods are in transit, and a distributor before customer payment. Capital Twin can connect these needs with potentially available funding, while RPT contributes predictive information about payment behavior, delivery performance, and other structured outcomes. The potential benefit is a more efficient allocation of liquidity across the value chain. Buyers may support suppliers; receivables may be assessed with better evidence; inventory may be evaluated with greater visibility; and financing providers may monitor events throughout an exposure's lifecycle. Such models must address ownership, assignment, security interests, priority, insurance, fraud prevention, duplicate financing, disputes, compliance, and participant rights. Operational evidence strengthens due diligence, but cannot replace enforceable legal rights or independent underwriting. The broader goal is Capital Optimization: assessing price and margin alongside liquidity, risk, financing needs, optionality, and the expected timing of cash realization. VIII. Implementation and The Autonomous Enterprise A Capital Twin implementation should begin with a defined economic use case, not an attempt to connect every system and object at once. Supplier financing, receivables visibility, goods-in-transit finance, inventory optimization, payment-delay prediction, foreign-exchange exposure, and liquidity forecasting are possible starting points. A focused pilot can establish whether the data is available, event definitions are consistent, predictions are useful, and financial translation changes a real decision. The data foundation should be built around governed business objects and relationships. The organization must define which source is authoritative for supplier identity, material, order, delivery, shipment, invoice, payment, ownership, and contractual status. It must map relationships across SAP and non-SAP systems and preserve the lineage of relevant events. RPT should be introduced where a structured predictive task exists and performance can be evaluated. Teams must define the target, observation window, population, available features, and cost of errors; predictions should be tested for calibration, stability, and sensitivity to changing data. Human review and ongoing monitoring remain necessary where decisions have material consequences. LLMs can support implementation and operation by interpreting questions, retrieving documentation, explaining model outputs, summarizing contract evidence, and coordinating calls to authorized services. But final outputs should be grounded in authoritative data, relevant RPT predictions, and approved financial rules. The conversational answer is the interface; governed data and validated calculations remain the basis of the decision. Financial translation must distinguish management estimates from accounting entries and regulatory measures, forecasts from contractual commitments, and indicators from approved decisions. A practical architecture can evolve progressively, beginning with one company, supplier group, product family, or financing process and then extending to other network participants. Existing SAP landscapes can provide useful event sources through standard processes, APIs, IDocs, EDI, and integration services; a complete technology replacement is not necessarily a prerequisite. Connecting systems is only the beginning. Consistent semantics, traceable evidence, sound prediction, legal enforceability, and decision governance turn connectivity into Capital Twin capability. The Autonomous Enterprise should not be understood as an organization that delegates every decision to a single AI model. It is an enterprise in which people, applications, agents, predictive models, and controlled services cooperate across connected processes. LLMs interpret intent and communicate with users. RPT generates predictive insights from structured business data. SAP applications execute operational and financial processes. Deterministic services enforce accounting, contractual, payment, and risk rules. People remain accountable for material judgments, exceptions, and governance. The Capital Twin gives this convergence a financial purpose. In the real economy, SAP records and coordinates orders, contracts, production, inventory, deliveries, and payments. RPT extracts predictive signals from structured enterprise data. Capital Twin translates the operational state and those predictions into liquidity, credit exposure, collateral potential, financing needs, foreign-exchange risk, and capital consumption. In the financial economy, SAP banking and risk capabilities can use this financial representation, together with their own data and controls, to support financing, risk assessment, monitoring, and financial products. The Capital Twin is not competing to build a better LLM. It is defining the financial architecture that allows structured intelligence from the real economy to become usable by the financial economy. SAP provides the business-process foundation. RPT brings predictive intelligence to the structured data on which those processes depend. LLMs make the architecture accessible, explainable, and easier to orchestrate. Capital Twin connects all three through a forward-looking model of economic value, liquidity, risk, and capital. The next competitive frontier in enterprise AI will not be decided by language capability alone. It will be decided by whether organizations can turn trusted business data into predictive economic intelligence and connect that intelligence to real financial decisions. That is the opportunity of the Capital Twin: not merely to automate what enterprises already do, but to change how the real economy and the financial economy understand, allocate, and mobilize capital. Connect and Stay Informed: Join the Conversation: Connect with fellow professionals in the SAP Banking Group on LinkedIn. https://www.linkedin.com/groups/92860/ Stay Updated: Subscribe to the SAP Banking Newsletter for the latest insights. https://www.linkedin.com/newsletters/sap-banking-6893665983048081409/ Join my readers on Medium where I explore Capital Optimization in depth. Follow for actionable insights and fresh perspectives https://medium.com/@ferran.frances Explore More: Visit the SAP Banking Blog for in-depth articles and analyses. https://sapbank.blogspot.com/ Connect Personally: Feel free to send a LinkedIn invitation; I'm always open to connecting with like-minded individuals. ferran.frances@gmail.com I look forward to hearing your perspectives. Kindest Regards, Ferran Frances-Gil. #SAPRPT #SAPPay #CapitalOptimization #SupplyChainFinance #DigitalTransformation #CapitalTwin #IFRS9 #ContractualGravity #Joule #FerranFrances