SAP Fiori and Document AI: Building a Unified Front-End Experience

Picture this. An accounts payable clerk receives a vendor invoice. She opens her SAP Fiori Launchpad, which looks clean and modern on her laptop. She clicks into the invoice processing tile, and right there, within the same familiar interface, she can see the vendor name, line items, PO number, and payment terms already extracted and waiting. She reviews, confirms, and posts. The whole thing takes two minutes. 

Now picture the old way. She receives the invoice, opens a classic SAP GUI transaction, squints at a cluttered screen designed in the 1990s, manually types every field, cross-references the PO in a different window, and eventually posts after ten minutes of context-switching. If something looked off, she would need to go back to the original PDF in her email, compare manually, and repeat. 

The difference between these two scenarios is not just a UX upgrade. It represents a fundamental shift in how document intelligence connects to SAP workflows. SAP Fiori built the modern front end. Document AI handles the extraction and classification. The gap between those two systems is where most enterprise implementations either succeed or fail. Bridging that gap cleanly, without forcing users back into old SAP screens, is exactly what this post covers. 

Why the Front-End Gap Matters More Than the Back-End 

Most discussions about Document AI in SAP environments focus on the integration plumbing: OData services, BAPIs, IDocs, RFC calls. The technical community spends a lot of energy on getting data from extracted documents into SAP tables. That part is well-documented. 

What gets discussed less often is the user experience on the other side of that pipeline. Even when extraction is working perfectly and data lands correctly in SAP, many implementations still route users to classic SAP transactions to review, approve, or correct that data. MIRO for invoice verification. ME21N for purchase orders. FB60 for vendor invoices. These transactions work, but they were never designed for the document-centric, mobile-friendly, contextual workflows that modern businesses expect. 

The result is a strange hybrid where a sophisticated AI system handles extraction, and a 1998-era screen handles the human decision. That friction point drives down adoption, increases error rates, and undermines the ROI of the AI investment. 

SAP Fiori changes this. Built on SAPUI5 and exposed through the Fiori Launchpad, it gives teams a framework for building clean, contextual, role-based apps that sit directly on top of SAP back-end logic. When you connect document extraction output to Fiori apps properly, the experience completely changes. 

What "Surfacing Cleanly" Actually Means 

When extracted document data surfaces cleanly in a Fiori app, a few specific things happen. 

The user sees extracted fields pre-populated in editable form fields, not in a separate review screen that requires copy-pasting. Confidence scores are present without being distracting, perhaps a subtle color indicator on fields that need a second look. The original document is visible in a side panel or embedded viewer, so the user can verify without switching tabs or applications. Actions like approve, reject, or route for escalation are available as clear buttons within the same screen. And if a field needs correction, the user edits it inline, not in a separate transaction. 

This is what unified means. The document, the extracted data, and the SAP workflow all live in the same Fiori screen at the same time. 

Getting there requires thinking through three layers: how extracted data reaches the Fiori app, how the Fiori app presents it, and how user actions flow back into SAP.

Layer One: Getting Extracted Data to the Fiori App 

SAP Fiori apps consume data through OData services. This is the foundation. Whether you are building a custom app or extending a standard one, the data layer speaks OData. So the first challenge is exposing extracted document data as an OData feed that a Fiori app can call. 

There are two common patterns for this. 

The first pattern routes document extraction results into SAP through a standard inbound interface, typically an IDoc or BAPI, which populates SAP tables. The Fiori app then reads those tables through a standard OData service. This keeps everything inside SAP and works well when the extraction output maps cleanly to existing SAP data structures. The downside is latency. The data takes a round trip through SAP back-end processing before the Fiori app can read it. 

The second pattern uses a middleware layer, often an integration platform or API gateway, to sit between the extraction engine and the Fiori app. Extracted data goes into the middleware, which exposes it as an API. The Fiori app calls this API directly to populate its fields, and only writes to SAP when the user confirms. This gives a faster, more responsive experience and allows richer metadata, like confidence scores and extraction provenance, to reach the front end without cramming it into SAP table structures that were never designed to hold it. 

Artificio uses the second pattern by default. The extraction output is a structured JSON payload with field values, confidence scores, document type classification, and original position metadata. This payload is available via REST API within seconds of document receipt. A Fiori app built on SAPUI5 can call this endpoint on page load and populate its form fields immediately, before the user even opens the record. 

The key implementation detail here is the document identifier. Every document in the extraction pipeline needs a unique ID that the Fiori app can use to fetch the right extracted data. In practice, this is usually the SAP document number (invoice number, PO number, delivery note number) extracted from the document itself and used as the lookup key. When the Fiori app loads a record, it calls the extraction API with that document number and gets back the extracted fields. 

Layer Two: Building the Fiori App to Present Extracted Data Well 

Standard SAP Fiori apps were not built with Document AI in mind. Many of them do not have a document preview panel, do not show field-level confidence indicators, and do not handle the "extraction in progress" state. So there is usually some customization required, either extending a standard app or building a custom one. 

The SAPUI5 framework makes this manageable. A few patterns work particularly well. 

Embedding the original document as a side-by-side panel is the most impactful change. When a user can see the scanned invoice on the left and the extracted fields on the right, they spend almost no time second-guessing the data. They glance at the original, see it matches, and approve. The PDF viewer can be embedded using the SAPUI5 PDFViewer control, which loads documents from a URL. That URL points to the original document stored in your document management system or the Artificio document store. 

Confidence-aware field highlighting gives users a visual shortcut for where to focus their attention. Fields with high confidence scores display normally. Fields with medium confidence get a light amber border. Fields with low confidence get a red border and a small warning icon. This is straightforward to implement in SAPUI5 using value states on input controls, and it dramatically reduces the time users spend reviewing clean extractions while still catching the cases that need attention. 

Inline editing within the same form, without navigating to a different screen, keeps the workflow tight. SAPUI5 Form controls support editable mode natively. When a user spots an extraction error, they click the field, correct it, and the corrected value is what gets submitted to SAP. The correction also feeds back to the extraction system as a training signal, which improves future accuracy. 

Action buttons scoped to the document type matter more than people expect. An invoice approval workflow has different actions than a delivery note confirmation. Building app variants by document type, each with the relevant action set, means users are never looking at buttons that do not apply to their task. 

Layer Three: Writing Confirmed Data Back to SAP Core 

When the user confirms the document in the Fiori app, the write-back to SAP needs to be clean and transactional. This is where the choice of integration pattern from Layer One becomes important again. 

If you used the direct-to-SAP pattern, the write-back is usually a BAPI call that updates the existing SAP document that was pre-created during inbound processing. The Fiori app sends the confirmed and possibly corrected field values, the BAPI updates the record, and the standard SAP posting logic runs. 

If you used the middleware pattern, the write-back goes through an API call that triggers the SAP creation or update. This is typically implemented as a POST to an OData service that maps to a function import backed by a BAPI or a Business Object. SAP S/4HANA exposes a growing number of these through its released API catalog, which covers invoice creation, purchase order confirmation, goods receipt posting, and more. 

The critical requirement in either case is that the Fiori app never creates a situation where extracted data sits in a non-SAP system indefinitely without being reflected in SAP. The confirmation action should trigger synchronous write-back, and the user should see a success or failure state before the screen closes. If the write fails, the user needs to know immediately, not find out later when a posting run fails. 

Where This Plays Out in Practice 

Accounts payable is the obvious starting point, but the same architecture applies across a wide range of document types in SAP. 

Vendor invoice processing is the most common. Extracted invoice data populates the Fiori MIRO-equivalent or a custom invoice review app. The user sees vendor name, invoice number, line items, tax amounts, and payment terms, all pre-filled. They confirm against the visible PDF and post. 

Goods receipt and delivery note matching is the second most common. When a delivery note arrives, the extraction engine pulls the line items and quantities. A Fiori app shows the expected delivery based on the open PO alongside the extracted delivery note data, with visual indicators showing matches and mismatches. The user confirms receipt for matching lines and flags discrepancies. 

Contract management benefits significantly from this pattern because contracts are long and complex. Rather than asking users to read a 40-page contract in SAP, a Fiori app can show the extracted key terms: effective date, expiry, counterparty, value, renewal clauses. The user reviews the extracted summary, checks the embedded document for any flagged sections, and moves to the next step. 

HR document processing covers offer letters, employment contracts, certificates, and identity documents. In the SAP SuccessFactors context, a Fiori app for onboarding can pull extracted data from candidate documents and pre-populate employee records, rather than asking HR coordinators to re-key everything. 

The Role of Confidence Scoring in User Trust 

One thing that separates a good Document AI integration from a mediocre one is how it handles uncertainty. Every extraction model produces confidence scores alongside field values. Low-confidence fields are the ones where the model was not sure, usually because of poor scan quality, unusual formatting, or a field type the model has not seen often. 

A common mistake is to hide these scores from users. The thinking is that showing uncertainty will undermine confidence in the system. The opposite is true. When users can see which fields the model is confident about and which ones need a second look, they trust the system more because they understand what it is and is not telling them. They spend their attention where it matters. 

The Fiori implementation of confidence scoring should be visual, not numerical. Showing a 0.73 confidence score next to a field is not useful to most users. Showing an amber field with a "Review" tag achieves the same result without requiring the user to understand what 0.73 means in context. 

Over time, as users correct low-confidence fields and those corrections feed back into the training pipeline, the amber and red fields become less frequent. Users notice this. The system improving visibly in response to their corrections is one of the most effective ways to build adoption. 

Avoiding the Hybrid Screen Anti-Pattern 

The most common way Document AI and Fiori integrations go wrong is what you might call the hybrid screen anti-pattern. This is where the Fiori app handles the review and approval steps, but any edit or correction still opens a classic SAP transaction. Users end up bouncing between two interfaces, which is worse than staying in classic SAP entirely because at least the classic approach is consistent. 

This happens when teams build the happy path in Fiori but leave the exception handling in classic SAP. The logic is usually that exception cases are rare, so it is not worth the development effort to build them in Fiori. But rare exceptions are often the cases where users spend the most time, so the experience of handling exceptions matters disproportionately. 

Building exception handling into the Fiori app does not need to be as complex as it sounds. Most exceptions fall into a small number of categories: field value looks wrong, document could not be matched to an existing SAP record, approval limit exceeded, or duplicate detected. Each of these can be handled with a specific UI pattern in the Fiori app. A mismatch alert with an edit option. An unmatched document queue with a manual match workflow. An escalation path to a senior approver. A duplicate warning with a link to the existing record. 

Building these patterns once and reusing them across document types means the development investment is spread across many workflows. 

Performance and Scalability Considerations 

A Fiori app that calls an external extraction API on page load has a dependency that standard SAP apps do not have. If the extraction API is slow or unavailable, the Fiori app degrades. This needs to be designed for explicitly. 

The right approach is asynchronous pre-fetch with a loading state. When a document enters the processing queue, extraction runs asynchronously. By the time a user opens the document in the Fiori app, the extraction result is already cached and ready to serve. The page load calls the cache, not the live extraction engine. Extraction latency becomes invisible to users. 

For documents where extraction has not completed yet, a clear loading state with an estimated ready time is better than a blank form. Most users are fine waiting 20-30 seconds if they can see the system working. 

Caching extracted results at the middleware layer also means the Fiori app is not blocked if the AI service has a transient issue. The cache holds the last good extraction result, and the app can display it with a timestamp so users know when extraction ran. 

What a Mature Implementation Looks Like 

Teams that have gone through a full SAP Fiori and Document AI integration build up a set of shared components that accelerate future document types. A document preview component that can be embedded in any Fiori app. A confidence indicator component that takes a score and renders the appropriate visual state. A write-back service layer that handles OData calls to SAP in a standardized way. A correction capture service that logs field edits and sends them to the training pipeline. 

With these building blocks in place, adding a new document type goes from a multi-month project to a few weeks. The extraction model training and the Fiori app configuration are done in parallel, and the shared infrastructure handles the connection between them. 

The organizations that get the most out of Document AI in SAP are not the ones that built the best single integration. They are the ones that built a platform for integrations that makes every subsequent document type easier than the last. 

The Business Case for Getting This Right 

The ROI argument for Document AI in SAP is usually made on extraction accuracy and processing speed. Those are real and measurable. But the larger gains come from user adoption, and user adoption lives or dies in the front-end experience. 

When the Fiori app is clean, contextual, and fast, users process more documents per hour with fewer errors. They trust the system because it shows them what it knows and what it does not. They stop using email to handle exceptions because the Fiori app has a path for exceptions too. The extraction engine gets better because correction data flows back into training. And the whole cycle reinforces itself. 

When the front end is poor, none of that happens. Extraction accuracy can be excellent, but if users still feel like they are fighting the interface, adoption stays low, manual rework persists, and the promised gains never materialize. 

Building the Fiori front end right is not optional for a successful Document AI deployment in SAP. It is where the value gets realized or lost.