Introduction
What if SAP Integration Suite could understand a PDF document instead of simply processing it?
Invoices, sales orders, and other business documents are often received as PDF attachments with different layouts and formats. Traditional document processing relies on predefined templates and parsing rules, which can be difficult to maintain.
In this blog, we build an end-to-end Generative AI document processing scenario in SAP Integration Suite. Using Claude as a practical example, we classify PDF documents, extract key business data, and use the structured result to route and process the document in SAP Cloud Integration (CPI).
We will also cover validation, human approval, exception handling, and key enterprise considerations when processing sensitive business data with Generative AI.
Business Scenario
The scenario is based on a shared business mailbox used to receive documents from customers and suppliers. Incoming emails can contain different types of PDF business documents, such as invoices and sales orders.
SAP Cloud Integration receives the email and extracts the PDF attachments. Each document is then sent to a Generative AI model, which identifies the document type and extracts the relevant business fields.
Based on the AI result, CPI can route the document to the appropriate processing flow. For example, an invoice can be prepared for an SAP S/4HANA supplier invoice process, while a sales order can be prepared for the sales order creation process.
Example document types:
- Supplier Invoice
- Customer Sales Order
- Purchase Order
- Unclassified / Unsupported Document
Example end-to-end flow:
[Diagram: End-to-end Generative AI document processing flow from email PDF attachment through SAP Cloud Integration and Generative AI to classification, data extraction, validation and downstream SAP processing]
The objective is to move from document-specific parsing logic to a more flexible approach where the AI model can understand different document layouts while SAP Cloud Integration remains responsible for orchestration, validation, mapping, routing, and integration with downstream SAP systems.
Building the SAP Cloud Integration Flow
The integration flow starts when an email containing one or more PDF attachments is received. Each PDF is processed independently by the Generative AI pipeline before the result is made available for further business processing.
The main processing steps are:
- Extract PDFs into Collection — extracts the PDF attachments from the email and prepares them for processing.
- Process Multiple PDF Attachments — uses a General Splitter to process each PDF independently.
- Prepare the Document Data — retrieves the file name and PDF content of the current document.
- Build GenAI Request — creates the SAP Generative AI Hub Orchestration request containing the prompt, document, tools and selected model.
- Call the Generative AI Service — sends the request through the AI Receiver Adapter.
- Process the AI Response — converts and processes the returned structured response.
- Router — determines the appropriate processing path based on the AI classification.
[Screenshot: Complete SAP Cloud Integration iFlow showing email intake, PDF extraction, document splitting, Generative AI processing, response handling and downstream routing]
The complete iFlow shows how Generative AI is incorporated into a conventional SAP integration process while keeping the integration and business processing logic within SAP Cloud Integration.
Extracting PDF Attachments
The first step is to extract the PDF attachments from the incoming email and prepare them for further processing. Since a single email can contain multiple documents, the integration flow collects all PDF attachments into a single XML structure.
The Groovy script reads the attachments, filters out non-PDF files, converts each PDF from binary content to Base64, and stores the result together with the original file name.
import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.StreamingMarkupBuilder
import groovy.xml.XmlUtil
import java.util.Base64
def Message processData(Message message) {
def attachments = message.getAttachments()
def builder = new StreamingMarkupBuilder()
def xml = builder.bind {
attachments {
attachments.each { fileName, dataHandler ->
def contentType = dataHandler.getContentType()
if (contentType?.toLowerCase()?.startsWith("application/pdf")) {
def pdfBytes = dataHandler.getInputStream().bytes
def pdfBase64 = Base64.encoder.encodeToString(pdfBytes)
file {
fileName(fileName)
fileContent(pdfBase64)
}
}
}
}
}
message.setBody(XmlUtil.serialize(xml))
return message
}[Code Snippet: Groovy Script – extracting PDF attachments, filtering PDF files, converting the content to Base64 and building the attachment collection]
The resulting message body has the following structure:
<attachments>
<file>
<fileName>invoice_001.pdf</fileName>
<fileContent>BASE64...</fileContent>
</file>
<file>
<fileName>sales_order_002.pdf</fileName>
<fileContent>BASE64...</fileContent>
</file>
</attachments>This collection is then passed to the next step, where a General Splitter processes each PDF independently. This allows multiple documents received in the same email to follow the same Generative AI processing logic without combining them into a single AI request.
Processing Multiple PDF Attachments
When an email contains multiple PDF documents, the General Splitter processes each document independently. The splitter uses the XPath expression /attachments/file to create a separate message for every <file> element in the collection.
In this example, Parallel Processing is disabled and Stop on Exception is enabled, ensuring that documents are processed sequentially and that an exception stops the overall processing.
[Screenshot: General Splitter – XPath expression /attachments/file, with parallel processing disabled and Stop on Exception enabled]
Each split message then continues through the same processing logic, starting with retrieving the file name and PDF content before sending the document to Generative AI.
Preparing the Document Data
After the splitter creates an individual message for each PDF, a Content Modifier is used to extract the document content and file name from the current XML element.
The values are stored as exchange properties, file_content and file_name, and will be used to populate the corresponding fields of the Generative AI request.
[Screenshot: Content Modifier – extracting the current PDF file name and Base64 content into exchange properties]
Building the Generative AI Request
The Build GenAI Request Content Modifier creates the JSON payload that will be sent to SAP Generative AI Hub. The request follows the SAP Generative AI Hub Orchestration format rather than a provider-specific API format.
SAP Orchestration V2 defines the request around the config, modules and prompt_templating sections, together with placeholder_values for dynamic values. The complete request structure is documented in the SAP Help Portal – Orchestration Workflow V2.
This harmonized interface provides access to multiple foundation models through a consistent orchestration interface rather than requiring CPI to call a provider-specific API. SAP describes Orchestration as providing unified access to multiple generative AI models through consistent code, configuration and deployment. See the SAP Help Portal – Orchestration for more information.
In this example, Claude is selected as the foundation model. The request contains the prompt, the PDF document, the available tools for document classification and field extraction, and the selected model.
[Screenshot: Build GenAI Request – beginning of the SAP Generative AI Hub Orchestration request]
[Screenshot: Build GenAI Request – prompt and message configuration]
[Screenshot: Build GenAI Request – tool definitions used for document classification and field extraction]
[Screenshot: Build GenAI Request – selected Claude model and completion parameters]
[Screenshot: Build GenAI Request – remaining request configuration and tool-calling settings]
The PDF is passed dynamically using a placeholder. The actual Base64 content of the current document is taken from the CPI exchange property file_content:
[Screenshot: Content Modifier – dynamically inserting the current PDF Base64 content into the Generative AI request]
The {{?pdf_base64}} placeholder is resolved at runtime using the file_content exchange property. This allows the same request structure to be reused for every PDF processed by the splitter.
For PDF input, SAP Orchestration supports a multimodal content item using type: file and file_data. The PDF can be supplied as Base64 data or, where supported, as a URL. The exact documented representation is available in the SAP Help Portal – Templating documentation.
The model parameters depend on the selected foundation model. For example, SAP documents max_completion_tokens as required for Anthropic models.
The classification tools used in this example follow the tool-calling mechanism provided by SAP Orchestration. Multiple tools can be defined, allowing the model to select the appropriate function based on the document and the tool definitions. See the SAP Help Portal – Tool Calling documentation for more information.
Calling the Generative AI Service
The next step is the AI Receiver Adapter, which sends the prepared request to SAP Generative AI Hub. In this example, the adapter uses the Orchestration - Completion operation.
[Screenshot: AI Receiver Adapter – Orchestration Processing configuration]
Orchestration provides a harmonized interface between SAP Cloud Integration and supported foundation models. The integration flow sends the Orchestration request, while SAP manages the interaction with the selected foundation model.
In this example, the request specifies an Anthropic Claude Sonnet model together with parameters such as the maximum completion tokens and tool-choice behaviour.
The AI Receiver Adapter is responsible for the connection and execution of the Orchestration request, rather than defining the prompt or document-processing logic itself.
[Screenshot: AI Receiver Adapter – connection configuration using OAuth 2.0 client credentials, AI resource group and orchestration deployment]
The connection uses an OAuth 2.0 client credential configuration stored in the SAP Cloud Integration security material. The orchestration deployment and AI resource group are configured in the adapter's Processing settings.
Demo: Classifying and Routing a Sales Order
With the integration flow in place, we can test the scenario using a sales order PDF. The document in this example is an ABB Australia Sales Order Acknowledgement, with sales order number 10099324 and a total order value of AUD 3,239.63.
[Screenshot: Sales Order PDF – example document submitted to the Generative AI processing flow]
After the PDF is sent to Generative AI, Claude identifies the document as a Sales Order and calls the route_sales_order tool. It extracts the order number, customer, date, total amount, currency and number of line items.
[Screenshot: Claude Response – Sales Order classification, selected tool and extracted business data]
The response is then converted from JSON to XML so that it can be processed by standard CPI steps.
Routing the Document
The CPI Router checks the extracted tool name using an XPath expression:
/root/content/name = 'route_sales_order'If the condition is true, the message follows the Sales Order route. The corresponding Message Mapping transforms the extracted data into the structure required by SAP S/4HANA.
[Screenshot: CPI Router – XPath condition checking for the route_sales_order tool]
The same pattern can be extended to other document types, such as invoices, purchase orders, and unclassified documents.
Demo: Classifying an Invoice
To demonstrate that the same approach can handle different document types, we can use an invoice PDF as a second example.
The document is an invoice issued by GlobalTech Manufacturing GmbH to Nordic Retail Solutions AB. It contains a typical invoice structure, including an invoice number, invoice date, sales order reference, line items, VAT, and total amount due.
[Screenshot: Invoice PDF – example invoice submitted to Generative AI]
After the document is submitted to Generative AI, Claude successfully identifies it as an invoice and selects the corresponding route_invoice tool. The response contains the extracted invoice number, vendor name, total amount, invoice date, due date, and currency.
[Screenshot: Claude Response – Invoice classification, selected tool and extracted invoice data]
This example demonstrates that the model can identify the document type and extract the relevant business information even though the document has a different structure from the Sales Order used in the previous example.
Human Approval Before Posting
Identifying a document and extracting its business data is only one part of the process. In a real enterprise scenario, the AI result should not necessarily lead directly to the creation or posting of a business document in SAP S/4HANA.
For example, a sales order identified by Generative AI could be prepared for creation in S/4HANA, but a business user may first need to review the extracted information and approve the transaction. The same principle can be applied to invoices and other financially relevant documents.
This introduces a human-in-the-loop step between AI-based document processing and the final business transaction:
PDF → Generative AI → Classification & Extraction → Validation → Human Approval → SAP S/4HANA
The approval step can be implemented using workflow capabilities available in SAP S/4HANA or through an additional approval application or process on SAP BTP.
This approach also separates two different responsibilities. Generative AI is responsible for understanding the document and extracting the relevant information, while the business user remains responsible for the final business decision.
Depending on the business risk and validation requirements, the process can be designed in different ways. Low-risk, highly predictable documents could potentially be processed automatically, while documents above a defined value threshold, documents with missing or inconsistent information, or documents requiring a business decision could be sent for manual approval.
Example control flow:
- AI classification and extraction – identify the document and extract the relevant fields.
- Business validation – check mandatory fields, values, customer or supplier information, and other business rules.
- Approval – a designated business user reviews and approves or rejects the proposed transaction.
- S/4HANA processing – after the required approval is obtained, the business document can be created or posted.
This provides a practical balance between automation and control. The AI can remove much of the manual effort involved in reading and entering information from PDFs, while the business retains control over the final transaction.
Handling Sensitive Business Data
One of the most important considerations when introducing Generative AI into document processing is data protection. Business documents can contain confidential commercial information, personal data, financial information, customer details, bank account information, and other data that an organisation may not want to send to an AI service.
For example, an invoice may contain supplier and customer information, addresses, payment details, bank account information, and transaction values. A sales order can contain customer information, product details, prices, quantities, and other commercially sensitive data.
Therefore, the question is not simply whether Generative AI can technically process the document. The organisation must first determine whether the document is allowed to be processed by the selected AI service and model.
SAP Generative AI Hub provides an enterprise-managed layer for accessing and orchestrating foundation models. SAP Orchestration also provides capabilities such as content filtering and data masking, which can be incorporated into an orchestration workflow where appropriate. See the SAP Help Portal – Orchestration documentation for details.
However, these capabilities do not remove the customer's responsibility for data protection. SAP documentation explicitly cautions users not to store personal data in prompts. A production implementation should therefore consider applicable privacy requirements, data classification, data residency, contractual requirements, and the organisation's internal policies before enabling real business documents for AI processing.
For this reason, a production implementation should include a data classification and security decision before the document is submitted to Generative AI.
For example, the integration could distinguish between:
- Approved documents – documents that are permitted to be processed by the selected AI service and model.
- Sensitive documents – documents that require masking, minimisation, or additional controls before AI processing.
- Restricted documents – documents that company policy does not allow to be submitted to the selected AI service and therefore require an alternative processing mechanism.
This can be implemented as an additional control before the AI Receiver Adapter:
PDF → Data Classification → Security Check → Generative AI / Alternative Processing
Where possible, data minimisation should also be considered. If the AI model only needs specific information to classify the document, unnecessary personal or confidential information should not be included in the AI request.
Conclusion
This example demonstrates how Generative AI can extend SAP Cloud Integration beyond traditional rule-based document processing. Instead of building separate parsing logic for every document layout, the integration can use a foundation model such as Claude to understand the document, identify its type, and extract the relevant business information.
At the same time, SAP Cloud Integration remains responsible for the integration logic. It manages the incoming documents, controls the processing flow, validates the AI result, routes the document, and transforms the extracted information into the structures required by SAP S/4HANA.
For a production implementation, AI-based document processing should be combined with appropriate business validation and, where required, human approval before creating or posting business documents. Data protection is equally important: organisations should determine which documents and data are permitted to be processed by Generative AI and apply the appropriate security and privacy controls.
The result is a flexible integration pattern in which Generative AI provides document understanding, SAP Cloud Integration provides orchestration and integration, and business processes remain in control of the final transaction.
This approach can be extended beyond invoices and sales orders to other business documents and processes, while continuing to use the same core integration pattern.
Bluesky
