SAP-RPT and the Evidence Economy: How Tabular AI Can Give the Capital Twin a Structural Competitive Advantage

1. The Missing Link Between Enterprise Data and Financial Intelligence The global economy generates an enormous volume of structured business information every day. Purchase orders, production records, inventory movements, transportation milestones, delivery confirmations, invoices, payment commitments and contractual obligations collectively describe how economic activity actually unfolds. Enterprise resource planning systems have spent decades organizing this information into relational structures. Yet a significant gap remains between managing the real economy and translating its operational reality into the financial language used to assess risk, allocate capital and determine financing costs. The Capital Twin is an architectural framework designed to bridge that gap. Its purpose is to connect the operational processes managed by enterprise systems with the financial models used by banks, insurers, investors and capital markets. Instead of relying exclusively on aggregated corporate financial statements and conventional credit assessments, the Capital Twin seeks to establish a more granular representation of the economic characteristics of individual assets, transactions and contractual commitments. The central principle is that the financing conditions of an economic asset should reflect not only its accounting value or the creditworthiness of its owner, but also its traceability, contractual protection, operational status, expected performance and recoverability. Achieving this requires more than integrating databases. It requires a mechanism capable of transforming structured operational information into reliable predictions, verifiable evidence and financially meaningful conclusions. This is where SAP's tabular artificial intelligence capabilities become strategically important. SAP-RPT, supported by Tabular AI on SAP and the SAP AI Core runtime, offers a technological foundation for making the Evidence Economy more scalable, predictive and economically actionable. The competitive opportunity lies in connecting this capability to the semantic and relational structure of enterprise processes and then translating its outputs into the language of capital markets. 2. Why Structured Business Data Requires a Different Kind of AI Most enterprise information is not originally created as free-form text. It exists in tables, transactions, master data, reference data and relationships among business objects. A purchase order has a supplier, purchasing organization, material, quantity, price, delivery schedule and contractual context. A goods movement references a material, plant, storage location and movement type. An invoice refers to commercial obligations, tax classifications, payment terms and accounting records. These relationships determine the meaning of the information. A conventional relational database can retrieve and combine records using SQL joins. Such joins remain essential for deterministic processing, reporting and data integration. But a join does not, by itself, predict whether a delivery will be late, whether a supplier is likely to fulfil a commitment or whether a particular combination of operational conditions indicates elevated financial risk. Those questions require analytical models that can identify patterns across structured observations. Large language models are powerful tools for interpreting language, generating content and coordinating complex workflows. However, converting structured business records into text and asking a language model to reason over them is not necessarily the most efficient approach for every numerical prediction or classification task. Tabular foundation models are designed specifically for this different problem. They work natively with structured data, learning patterns across rows and columns and using the relationships represented in the data to produce predictions. SAP-RPT stands for Relational Pretrained Transformer. SAP describes it as a fully managed, table-native foundation model that supports predictive tasks such as classification and regression through in-context learning, without requiring a separate training or fine-tuning cycle for every use case. SAP also describes explainability capabilities that help users identify which input columns and contextual records influenced a prediction. SAP-RPT product information. This design is particularly relevant to enterprise environments, where many business decisions depend on structured data that changes continuously. Rather than building and maintaining an independent predictive model for every narrowly defined business problem, an organization can evaluate whether a pretrained tabular model can support multiple use cases through appropriately designed prediction requests and contextual examples. That does not eliminate the need for data preparation, model evaluation, business-rule implementation or validation. It can, however, reduce the amount of task-specific model development required. For the Capital Twin, this distinction has strategic significance. The objective is not simply to analyze enterprise data faster. It is to make predictive analysis economically practical across a much broader universe of assets and business processes. 3. From Relational Tables to Economic Meaning The competitive potential of SAP's tabular AI becomes clearer when we examine the structure of SAP enterprise data. SAP systems do not merely store isolated business facts. They organize them through business objects, identifiers, document relationships, master data, organizational structures, domains, permitted values and application-level validation rules. These elements help define what a record represents and how it relates to other records. Consider a shipment of industrial components. Its economic significance may depend on a network of related information: The purchase order establishes the commercial requirement. The supplier and material master data identify the parties and goods. Production records indicate whether the goods have been manufactured. Warehouse and transportation records describe their location and movement. Delivery milestones indicate whether contractual dates are being met. Inspection records provide evidence about quality status. Customer orders and contractual commitments establish the expected commercial outcome. Invoices and payment terms describe the associated financial obligations. A conventional query can join these records to construct a consistent view of the transaction. A tabular predictive model can then use relevant structured features to estimate outcomes such as transportation lead time, delivery delay, payment lateness or other defined business variables. The distinction is important: relational integration establishes what the records say; predictive modelling estimates what is likely to happen; evidence validation establishes what can be relied upon financially or contractually. These are complementary functions, not interchangeable ones. A domain value or reference-table entry can establish that a field contains an allowed value. It does not automatically prove that the underlying event occurred as reported. Likewise, a prediction can indicate a high probability of successful delivery without establishing legal ownership of the goods or the enforceability of a customer commitment. The Capital Twin needs all three dimensions. First, the operational information must be assembled and interpreted correctly. Second, predictive models must evaluate relevant uncertainties. Third, deterministic controls, contractual validation and audit mechanisms must establish which conclusions can legitimately support a financial decision. This is the foundation of the Evidence Economy. 4. The Evidence Economy: Making Operational Reality Financially Usable The Evidence Economy is the principle through which the Capital Twin seeks to transform verifiable business events into information that can support financial decisions. Traditional credit assessment often begins with the company requesting financing. Its financial statements, debt levels, credit history, available collateral and repayment capacity provide the basis for determining its risk profile. These factors remain essential. Nevertheless, they may not fully capture the changing characteristics of every asset or transaction within a complex supply chain. Two companies with similar financial profiles may have very different operational exposures. Equally, two transactions involving the same company may have different risk characteristics because their contractual protection, traceability, delivery reliability, payment arrangements and recovery prospects differ. The Evidence Economy seeks to make these differences visible. Its analytical sequence is: Operational events → Relational context → Predictive intelligence → Verified evidence → Financial risk assessment → Potential capital-cost improvement. For example, an inventory position supported by a confirmed customer order, traceable transportation records, valid insurance and a strong delivery history may offer a different risk profile from inventory whose destination, contractual status or recoverability is uncertain. The model does not assume that the first position automatically deserves cheaper financing. It provides a basis for investigating whether the difference is material, measurable and acceptable to a financing institution. Evidence becomes economically useful when it changes a decision. That decision might concern whether an asset is eligible for financing, how much exposure should be recognized, what additional protection is needed, whether a transaction should receive enhanced monitoring or what pricing conditions are appropriate. The resulting framework could support a shift from evaluating only the financial condition of a company to assessing the economic characteristics of the specific transactions being financed. For this to work, the system must process evidence at a frequency and cost consistent with the economics of the underlying activity. Manual investigation may be reasonable for a small number of high-value transactions. It becomes less practical when the objective is to evaluate millions of interdependent business events across international supply chains. This is the point at which tabular AI becomes strategically relevant: it can help make the predictive component of the Evidence Economy repeatable across large numbers of structured transactions. 5. The Correct Technological Architecture: SAP-RPT, Tabular AI and SAP AI Core The technology should be understood as a combination of distinct capabilities rather than a single product performing every function. SAP-RPT is the predictive model. It is designed to make predictions from structured relational business data through classification, regression and in-context learning. Tabular AI on SAP is the broader capability for operationalizing tabular intelligence. It brings together tabular foundation models, orchestration, contextualization and governance to support predictive workflows across enterprise use cases. SAP AI Core provides the managed runtime and deployment environment through which models and tabular workflows can be operated at enterprise scale within the SAP Business AI Platform. SAP's architecture guidance recommends using Tabular AI orchestration for most production scenarios because it can manage contextual data selection and prediction requests. Direct model API access remains available for evaluation and specialized integrations. SAP architecture guidance. This architecture matters because enterprise prediction is not simply a matter of sending a table to a model. A production workflow must identify the prediction target, select appropriate input features, retrieve relevant historical examples, manage contextual information, execute the prediction, record the result and evaluate whether the model performs adequately on representative data. It must also deal with changing business conditions, incomplete records, data access permissions, monitoring and model governance. Tabular orchestration can help standardize these tasks and reduce the need to implement every element separately for each use case. For the Capital Twin, this creates the possibility of a reusable predictive layer supporting several economic functions. The same general architecture could be evaluated for delivery reliability, payment-delay estimation, supplier performance, inventory realization, operational disruption and other variables relevant to financing decisions. Each use case would still require its own definition, validation and assessment of predictive performance. A common platform does not mean that one prediction model automatically solves every financial problem. The strategic benefit is the potential to reuse the infrastructure and modelling approach across multiple processes rather than treating each predictive problem as an isolated technology project. 6. Why SAP's Enterprise Context Can Create a Competitive Advantage The potential differentiation of SAP's tabular AI is not based solely on the existence of a pretrained model. Other organizations can develop or deploy models for structured data. The more significant opportunity lies in the combination of table-native predictive technology with enterprise process knowledge, structured business information and an established environment for operationalizing AI. SAP systems contain extensive representations of how organizations purchase, manufacture, transport, sell, invoice and account for economic activity. This context can help developers identify relevant business variables, understand how operational records relate to each other and formulate predictive questions grounded in actual enterprise workflows. SAP's tabular AI offering also supports data beyond SAP systems, so the opportunity is not necessarily limited to transactions originating in a single ERP environment. Tabular AI on SAP. For the Capital Twin, three potential advantages follow. 6.1 Reusable predictive capability If a pretrained tabular model can deliver acceptable results without requiring a separately trained model for every narrowly defined use case, development and maintenance effort may be reduced. This matters because the Evidence Economy requires more than one prediction. It potentially requires many different predictions across procurement, manufacturing, logistics, contractual performance and financial risk. The economics of the architecture improve if predictive capabilities can be reused without compromising accuracy or reliability. 6.2 Operational integration Predictions become more valuable when they can be integrated into existing business workflows rather than remaining isolated analytical outputs. A delivery-risk prediction, for example, could inform inventory planning, exception management or a Capital Twin assessment of an asset's financing characteristics. Tabular AI on SAP is designed to make predictive insights available through business workflows, custom applications and Joule-related capabilities. The specific integration required for the Capital Twin would need to be designed and validated. 6.3 Traceability and governance Financial decisions require more than a prediction score. They require an explanation of which data was used, what the model estimated, which controls were applied and how the output affected the final decision. SAP documents features for tracing predictions to influential rows and columns. These explanations are useful diagnostic signals, although they should not be treated as proof of causality or as a substitute for independent validation. The Capital Twin could build on this foundation by retaining the source evidence, prediction outputs, applicable financial rules and resulting decisions in an auditable chain. The competitive opportunity therefore lies in the integration of predictive capability, business context, workflow execution and financial governance. 7. Business Case: Financing Inventory and Goods in Transit Consider a hypothetical international manufacturer with annual revenue of €2.4 billion. The company has €150 million tied up in work in progress, inventory, consignment stock and goods in transit. It also has substantial contractual commitments and foreign-exchange exposures associated with its international supply chain. The company finances part of its working capital through banks. Financing conditions depend on its credit profile, the nature of the assets, the available guarantees and the lender's risk assessment. The manufacturer wants to determine whether a more granular evaluation of its operational evidence could improve financing terms. The objective is not to assume that SAP-RPT automatically reduces borrowing costs. It is to test whether structured operational evidence can identify meaningful differences in transaction risk that conventional assessments do not fully capture. 7.1 The initial problem The company faces several sources of uncertainty: Some shipments arrive later than expected. Production delays affect the timing of customer deliveries. Inventory positions have different levels of traceability and contractual protection. Payment delays create uncertainty about the timing of cash inflows. Financing assessments do not always incorporate the latest operational evidence. The company has information relevant to these issues across its ERP, warehouse, logistics, order-management and financial systems. However, that information is distributed across related business objects and is not necessarily translated into a unified, continuously updated financial assessment. 7.2 Building the evidence model The Capital Twin establishes a structured representation of the relevant assets and transactions. For each financing candidate, it assembles the applicable evidence, potentially including: Purchase-order and sales-order references. Material and inventory characteristics. Production and inspection milestones. Shipment identifiers and transportation status. Contractual delivery dates and customer commitments. Insurance and collateral documentation. Historical delivery and payment performance. Relevant invoice, collection and foreign-exchange information. Deterministic validation rules check the consistency of the records, identify missing evidence and detect conflicting or duplicated claims. Where necessary, additional controls verify that contractual rights, ownership, insurance coverage and other legal or financial requirements are satisfied. The result is a structured dataset representing the current operational and contractual state of the assets under consideration. 7.3 Applying SAP-RPT SAP-RPT can then be evaluated for selected prediction tasks. For example, one task might estimate the expected transportation lead time for a shipment using structured variables such as material, origin, destination and goods-issue date. SAP itself uses transportation lead-time prediction as an example of a tabular AI use case. Other candidate tasks could include payment-delay classification or delivery-performance estimation, provided that suitable historical examples and reliable target variables are available. The model is evaluated against representative holdout data that was not used as contextual examples for the corresponding prediction. The assessment should compare its performance with relevant baselines, including existing operational forecasts and appropriately chosen alternative models. The organization should measure not only average prediction accuracy but also performance across different suppliers, routes, product classes and operating conditions. A model that performs well on average but fails on a high-risk subset may be unsuitable for a financing decision. Where results are acceptable, the prediction workflow can be integrated into the Capital Twin's evidence and risk-assessment processes. 7.4 From operational predictions to financial decisions Suppose the model estimates that a particular shipment is likely to arrive later than its contractual delivery date. That prediction does not itself establish a financial loss. The Capital Twin must evaluate the potential consequences. Would the delay postpone customer payment? Could it trigger contractual penalties? Is substitute inventory available? Does insurance cover the relevant event? Would the delay materially affect the lender's recovery prospects? The financial model then assesses how these factors affect the transaction's risk profile. A different shipment might have a stronger delivery record, better contractual protection and more reliable payment arrangements. Its financing assessment could therefore differ, provided that the relevant evidence is verified and the lender's methodology recognizes the difference. The purpose is to enable financing decisions to reflect the characteristics of individual assets and transactions rather than relying exclusively on a company-level credit classification. 7.5 Illustrative financial assumptions Assume the following hypothetical figures for the manufacturer: Business-case parameterIllustrative assumptionAnnual revenue€2.4 billionRelevant inventory and goods-in-transit pipeline€150 millionAverage financing balance potentially affected€100 millionBaseline annual financing rate on that balance6.0%Hypothetical rate improvement after lender validation0.20 percentage pointsAnnual implementation and operating cost€250,000 The €100 million financing balance is an assumption for the example, not the entire €150 million operational pipeline. The 20-basis-point improvement is also hypothetical; it is not an expected or guaranteed result of SAP-RPT. At the assumed baseline rate, annual financing expense on the relevant balance would be: €100 million × 6.0% = €6 million. If a lender independently verified the evidence, accepted the resulting risk assessment and agreed to reduce the rate by 20 basis points, the annual financing benefit would be: €100 million × 0.20% = €200,000. After the assumed €250,000 annual operating cost, the net annual benefit would be negative €50,000. This first scenario demonstrates an important point: even a technically successful predictive system does not necessarily produce an attractive business case. The benefit must exceed the full cost of data integration, technology, validation, governance and operation. Now consider a second scenario in which the accepted financing improvement is 40 basis points on the same €100 million balance. The annual financing benefit would be €400,000. After the €250,000 operating cost, the net annual benefit would be €150,000, before implementation costs, taxes and any additional effects. The business case becomes more attractive if the architecture also reduces operational losses, improves working-capital utilization or supports additional financing opportunities. Those benefits should be measured independently to avoid double counting. The example does not establish that SAP-RPT will generate a 20- or 40-basis-point reduction. It demonstrates how the Capital Twin could connect a measurable financing outcome to the economic value of verified evidence. 7.6 What must be proven in a pilot? A credible pilot should answer five questions. First: Does the model predict better? Compare SAP-RPT with existing forecasting methods and relevant alternative models using representative holdout data. Second: Is the evidence reliable? Test the completeness, consistency, provenance and contractual validity of the operational records. Third: Does the prediction improve a financial decision? Demonstrate that the output changes a defined risk assessment, eligibility decision, monitoring requirement or pricing recommendation. Fourth: Will a financing institution recognize the improvement? Obtain an explicit assessment from the relevant lender or funding partner. A lower predicted operational risk does not automatically imply a lower regulatory capital requirement or borrowing rate. Fifth: Does the economics justify the system? Calculate total integration, model-operation, governance and financing costs against verified benefits. Only after these questions have been answered should the organization consider scaling the approach across additional assets and processes. 8. Scaling the Evidence Economy Across the Enterprise The previous example involves inventory and goods in transit. The same broad architecture could be evaluated in other areas of the enterprise. In manufacturing, predictions of production completion and quality-related delays could support better assessments of contractual performance. In logistics, shipment reliability and exception detection could help identify assets whose delivery or recovery prospects differ materially. In procurement, supplier-performance predictions could inform operational resilience assessments and the evaluation of contractual dependencies. In receivables management, payment-delay predictions could improve cash-flow forecasting and the identification of exposures requiring additional monitoring. In insurance, structured asset, maintenance and incident information could support selected risk-assessment workflows, subject to the requirements of the specific insurance model. Each application would require its own evidence definitions, model evaluation and financial interpretation. The objective is not to use one universal prediction as a substitute for domain-specific analysis. Instead, the architecture could provide a common mechanism for converting structured business information into validated predictive outputs and then connecting those outputs to defined financial decisions. This creates a potential network effect within the enterprise: once the data relationships, governance mechanisms and integration patterns are established, additional use cases may become less expensive to implement. That effect is not automatic. It depends on data quality, reuse of existing components, model performance and the degree to which the use cases share meaningful structures. Nevertheless, the possibility of reusing predictive infrastructure across multiple business processes is strategically important. The Evidence Economy requires breadth as well as depth. Its potential value comes from evaluating many different kinds of economic activity, not from optimizing a single isolated prediction. 9. The Capital Twin: Translating Evidence into Capital-Markets Language The final step is the one that differentiates the Capital Twin from a conventional predictive analytics initiative. SAP-RPT can estimate outcomes from structured business data. Tabular AI on SAP can help operationalize those predictions. Neither component independently determines the correct cost of capital for an asset. That requires a financial architecture. The Capital Twin must translate verified operational and contractual evidence into the variables and concepts used by financial institutions. Depending on the transaction, these may include: Probability of default (PD). Loss given default (LGD). Exposure at default (EAD). Expected credit loss. Collateral eligibility and valuation. Liquidity and funding requirements. Regulatory capital treatment. Return on risk-adjusted capital (RAROC). Contractual protection and recovery expectations. Market-based financing spreads. The relationships among these variables must be defined through appropriate financial models, contractual structures and regulatory rules. For example, a better delivery forecast might reduce uncertainty about the timing of customer payment. But the impact on credit risk depends on the contract, counterparties, recovery rights and other relevant factors. The effect on regulatory capital depends on the applicable framework and whether the relevant requirements are satisfied. The Capital Twin therefore acts as the bridge between predictive operational intelligence and financial interpretation. Its objective is to establish a more granular financial representation of economic assets, one in which the cost and availability of capital can reflect their measurable characteristics rather than being determined exclusively by aggregated company-level assessments. The word Twin is important in this context. The ambition is not merely to produce a report or a risk score. It is to maintain a representation of the economic and financial state of assets and transactions as their operational, contractual and predictive characteristics change. This representation can then inform financing decisions as new evidence becomes available. The architecture would need to preserve the distinction between observed facts, model estimates, contractual conclusions and financial decisions. That distinction is essential for auditability, responsible use and acceptance by external financial institutions. 10. Why This Could Become a Structural Competitive Advantage The competitive proposition rests on the combination of four capabilities. First, enterprise process structure. SAP environments already organize large volumes of business activity into relational records and interconnected operational processes. Second, table-native predictive intelligence. SAP-RPT is designed to generate predictions from structured data without requiring a separate training cycle for every use case. Third, operational orchestration. Tabular AI on SAP and SAP AI Core can help integrate prediction workflows, contextual data selection, execution and governance. Fourth, financial interpretation. The Capital Twin adds the architecture required to translate operational evidence into risk, collateral, liquidity and capital-market concepts. No individual capability is sufficient by itself. A relational database can store and connect business records but cannot automatically establish their financial implications. A predictive model can estimate outcomes but cannot independently verify legal rights or determine regulatory treatment. A financial model can price risk but may lack sufficiently granular operational evidence. The opportunity arises when these capabilities are connected. The potential competitive advantage is therefore not that SAP-RPT makes every query faster or that it replaces all existing financial models. It is that the broader architecture could make the systematic evaluation of operational evidence more economically viable across a large number of transactions. If this can be demonstrated in practice, the Capital Twin could move beyond isolated predictive use cases toward a reusable framework for evidence-based capital allocation. 11. The Validation Agenda: From Architecture to Demonstrable Value A strong strategic proposition must ultimately be supported by measurable results. The first requirement is a technical benchmark. The organization should measure prediction quality, latency, throughput, stability and operating cost for representative enterprise datasets. The second requirement is an evidence benchmark. It should measure how frequently records are incomplete, contradictory, duplicated or insufficiently supported, and how effectively the controls identify these issues. The third requirement is a financial benchmark. It should establish whether the evidence and predictions materially improve a defined decision compared with the existing process. The fourth requirement is external validation. Lenders, insurers or other financial counterparties must confirm which outputs they can incorporate into their own decisions and under what conditions. Finally, the complete business case must account for technology costs, integration effort, governance, ongoing maintenance, financing benefits and any independently verified operational savings. The model's explainability features can help analysts understand which rows and columns influenced a prediction, but those signals must be interpreted carefully. They do not by themselves establish causation, legal validity or financial materiality. Likewise, an accurate prediction is not necessarily economically valuable. The relevant question is whether it improves a decision enough to justify the cost of obtaining and acting on it. This validation agenda is not a weakness in the Capital Twin proposition. It is the mechanism through which the proposition can become credible to enterprise customers and financial institutions. Conclusion: Making the Evidence Economy Computationally and Financially Viable The next frontier in enterprise AI is not simply generating more information. It is using the structure of business data to make better decisions about the economic activity that information represents. SAP-RPT offers a model designed specifically for structured relational data. Tabular AI on SAP provides capabilities for operationalizing tabular predictions, while SAP AI Core supplies the managed runtime and orchestration environment. Together, these technologies can provide important building blocks for the Capital Twin. Their strategic relevance lies in making it more practical to interpret operational events, predict business outcomes and produce repeatable analytical outputs across multiple enterprise processes. The Evidence Economy supplies the next step: establishing which outputs are supported by reliable evidence and how that evidence changes the assessment of an asset or transaction. The Capital Twin then translates those assessments into the language of financial institutions and capital markets, connecting operational characteristics with risk, collateral, liquidity, capital requirements and potential financing costs. The result would not be a system in which AI automatically declares every asset financeable or assigns a definitive price to every transaction. It would be an architecture in which verified evidence can support more granular, timely and economically grounded financial decisions. The distinction is fundamental. SAP-RPT helps turn structured enterprise data into predictive intelligence. The Evidence Economy turns that intelligence, together with verified business facts, into financially usable evidence. The Capital Twin translates that evidence into capital-markets language. If validated at scale, this combination could create a meaningful competitive advantage: enabling financial institutions to assess the economic reality behind assets and transactions with greater precision, and potentially to allocate and price capital in a way that more closely reflects the risks and opportunities of the real economy. The ultimate measure of success will not be the number of tables processed or predictions generated. It will be whether the architecture produces demonstrably better decisions and measurable economic value. 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. #SAPBusinessAIPlatform #ContractualGravity #CapitalTwin #DigitalTransformation #FinancialTwin #SAPPay #CorporateTreasury #BusinessBackbone #FutureOfFinance #CapitalOptimization #FerranFrances