Document AI: Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 9, 2026 · 14 min read

Where This Article Sits#

This is the Document AI installment of the L2-D AI series. Each article in the series is independent, but consultants framing a Business AI scoping conversation usually need at least D01 (overview), D03 (GenAI Hub), and this one.

References#

1) Document AI: Architecture and Use#

“Document AI” on BTP is an umbrella for four distinct capabilities. Knowing which one a requirement maps to is the first decision a consultant makes — and the most common scoping mistake is choosing the wrong one.

They are not substitutes.

2) How It Connects to S/4HANA#

                            ┌──────────────────────────┐
   Email / Fiori Inbox  ───►│ SAP Build Process Auto.  │
   Upload / Mobile Cap.     │  Process Document action │
                            └──────┬───────────────────┘
                                   ▼
                            ┌──────────────────────────┐
                            │ Document Classification  │ (optional but recommended
                            │  -> document_type        │  in mixed-document channels)
                            └──────┬───────────────────┘
                                   ▼
                            ┌──────────────────────────┐
                            │ DOX (BTP)                │
                            │  + Custom Model (if any) │
                            └──────┬───────────────────┘
                                   ▼
                            ┌──────────────────────────┐
                            │ SPA confidence gate      │
                            │  (human-in-the-loop UI)  │
                            └──────┬───────────────────┘
                                   ▼
                       ┌──────────────────────────────────┐
                       │ S/4HANA Cloud (public)  via      │
                       │   pre-shipped DOX scenario       │
                       │ S/4HANA Cloud (private) / on-prem│
                       │   via OData destination service  │
                       └──────────────────────────────────┘

For S/4HANA Cloud public edition, SAP ships pre-configured DOX content for supplier invoices and PO confirmations — integration is a configuration exercise. For S/4HANA Cloud private and on-premise, it is a customer build, including the Cloud Connector or equivalent egress. GenAI Hub grounding sits on a different path entirely: it does not feed S/4HANA postings.

Key point: Document AI is not “an S/4HANA feature.” It is a BTP service that S/4HANA consumes. Treating it as a Fiori toggle leads to under-scoped network and licensing work in every project.

3) Maturity Map#

Maturity is not uniform across the family. The same project can use one capability that is production-ready and another that is still early adopter — judge each one on its own.

4) Requirements Checklist#

The §3 Maturity Map answers “is it ready?” This section answers “are we ready?” Build one per-capability checklist into every Business AI scoping document.

DOX — pre-trained models (invoices, POs, paystubs)#

Document Classification#

DOX — Custom Models (Schema)#

GenAI Hub document grounding#

Cross-cutting (any Document AI deployment)#

5) Decision Criteria#

The three questions to ask first#

Q1. What measurable inefficiency in document handling are we removing, and what is its current cost?

If the customer cannot describe the pain in business terms — invoices per month, FTE hours of data entry, days of cycle time — Document AI is not the right project to start. A vague “we want to automate documents” almost always becomes a stalled PoC.

Q2. Where do these documents come from, in what languages, in what quality, and where must the data sit?

Answer this before talking about models. Unsupported scripts, phone photos, or handwritten markups are not rescued by fine-tuning. If the data must remain in a region where DOX is not provisioned, the conversation is about regional rollout, not AI.

Q3. Who owns the post-extraction process — the confidence threshold, the human review queue, the model lifecycle — and do they have budget?

Document AI is not a one-time install. Custom Models age, supplier mixes change, classification taxonomies expand. Without a named owner with year-two budget, someone declares “the AI doesn’t work” within 18 months.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

These are not implementation bugs. They are requirements-stage failures that cause Document AI projects to under-deliver after go-live, and every one of them is preventable in scoping.

Failure 1: Language and document-type assumed in scope without checking the pre-trained list

Korean / Thai / Arabic invoices return useless output in PoC. The fix becomes a Custom Model program nobody scoped. Avoid this by reading the per-document-type language coverage table during requirements, not during testing.

Failure 2: No upstream Document Classification in a mixed-document inbox

The calling system submits a credit memo to the invoice model. Every field is wrong. The team blames the model when the cause is missing routing. Always design Classification + DOX as a pair when the inbound channel carries more than one document type.

Failure 3: No human-in-the-loop on transactional postings

Without a confidence gate, low-confidence postings reach finance, get reversed manually, and the business loses trust within one quarter. SPA provides the HITL pattern out of the box; not using it is a scoping decision, not a constraint.

Failure 4: Source documents are below the operating envelope

Phone photos, handwritten markups, scans below 200 DPI — below the floor where any document AI works. Treat document-quality as a real requirement and fix the intake channel before automating it.

Failure 5: Custom Model program with no owner and no lifecycle plan

A Custom Model is published at go-live, then nothing changes for 18 months. Suppliers add new layouts; F1 silently degrades; nobody is accountable. Custom Models require a named owner, a labeled-sample backlog, and a publish-and-retire cadence.

Failure 6: Network path from on-prem S/4HANA to BTP not approved

The project assumes BTP services are reachable; security review opens in month four; integration blocks for two months waiting for Cloud Connector or egress approval. Raise this in week one of architecture work, not week six.

Failure 7: GenAI Hub grounding promised for structured posting

A stakeholder sees an LLM answer “what is the invoice total” correctly during demo and asks for the same flow to post invoices. Grounding is non-deterministic and bypasses confidence semantics. Use DOX for structured extraction; reserve grounding for unstructured Q&A.

FAQ#

Q: Does Document AI work on SAP S/4HANA on-premise, or only S/4HANA Cloud?

Both, but the integration shape differs. S/4HANA Cloud public edition has pre-shipped DOX content for supplier invoices and PO confirmations — turn it on and configure. S/4HANA Cloud private and on-premise are customer build projects: BTP entitlement, destination service, and (for on-prem) Cloud Connector or approved egress.

Q: How is DOX licensed, and where is the surprise cost?

Production usage is metered in blocks of 100 documents (blocks_of_100), billed via CPEA / cloud credits. The free default plan is evaluation-only. Two surprises in real projects: (a) Custom Model training and inference are charged separately on top of base DOX; (b) Premium plan is required for files over 20 MB or 10 pages and is quoted, not list-priced. Build both into year-one and year-two budgets.

Q: When should we descope Document AI from a project?

When any of the following is true: documents in unsupported scripts; handwritten or phone-photographed input; unbounded supplier population with no Custom Model budget; no HITL budget for low-confidence rows; the customer cannot quantify the inefficiency. “Walk away” is a real consultant deliverable here — promising 95% accuracy on Korean handwritten delivery notes is malpractice.

Q: Can Generative AI Hub replace DOX for invoice extraction?

Not as of 2026, and SAP does not market it as a replacement. GenAI Hub grounding solves a different problem (Q&A over arbitrary text). For structured extraction with confidence semantics and predictable per-document cost, DOX remains the path. Combining DOX for structured fields with GenAI for free-form clauses is increasingly common, but each side keeps its own confidence and review pattern.

Q: How do we document a Document AI requirement so it survives handover to delivery?

Write it as a quartet: (1) the named capability (DOX pre-trained invoice / Classification / Custom Model schema X / GenAI grounding), (2) the in-scope language and document-type list with per-language field-coverage tables attached, (3) the confidence threshold and human-review workflow, (4) the network and licensing prerequisites with a named owner. Without all four, the requirement is incomplete and will be reshaped during delivery.

Q: How accurate is DOX in practice, and how should we handle suppliers that change layouts?

For typed European-language invoices on a bounded supplier set, header field accuracy reaches 95%+ and line-item F1 lands at 85–90% after several weeks of feedback-loop tuning. The “last 5%” comes from constraining the supplier population or human-in-the-loop on low-confidence rows — it is not delivered by the model alone. For high-volume suppliers that change layouts, train a per-supplier Schema Custom Model and own its lifecycle. For long-tail suppliers with frequent drift, do not chase each format with a model; route them through a confidence gate and accept higher human review on that segment.

Summary#

Document AI on BTP is a portfolio, not a product. DOX with pre-trained models is production-ready for typed EU/US invoices, POs, and paystubs; Document Classification is the under-used routing layer; Custom Models extend coverage when suppliers are bounded and labeling budget exists; GenAI Hub grounding is for unstructured Q&A, not transactional postings. The consultant value is reading the customer’s document corpus, language tier, quality floor, and posting workflow and saying — accurately — which capability fits, what the prerequisites are, and where the honest answer is to walk away. Promise inside the envelope, refuse outside it, and ship the human-in-the-loop step every time.

What to Read Next#