Diagnosing a landscape mismatch between BPA and SAP Document AI on trial, and building a reusable extraction flow around it.
Introduction
In the first post of this series, we built an invoice approval workflow in SAP Build Process Automation, triggered by a manually filled form. The natural next step is to remove that manual step — read the invoice straight from a PDF and feed the extracted data into the same approval process.
That’s exactly where this post started. But before we could get to the approval logic, we ran into a connectivity issue between BPA and SAP Document AI that’s specific to trial landscapes. This post covers how we diagnosed it, the workaround that actually gets extraction working, and the one limitation that comes with it.
The Error
The first attempt was the obvious one: use BPA’s built-in “Add a Document Template” wizard to register a template against our invoice schema. It failed immediately, before any real document was even involved.
SAP_IPA_28014 — the Document Information Extraction call fails with a 400 Bad Request, right at the template creation step.
Swapping the approach and trying the built-in Extract Data (Pre-Trained Model) activity directly against our sample invoice hit the same wall.
Extract Data (Pre-Trained Model) configured against a sample invoice PDF.
What Didn’t Work
Our first instinct was that this was a subscription/entitlement glitch — a stale binding between the BPA and Document AI subscriptions. We re-subscribed both services from scratch a couple of times, on the theory that it would force a fresh landscape mapping. It didn’t change anything; the same 400 kept coming back.
Finding the Actual Cause
The real answer came from comparing what URL the failing call was actually hitting against what our trial tenant’s URL actually is.
The Test Console error for the built-in activity exposes the full request, including the URL it tried to call:
The built-in Extract Data activity was calling https://us10.doc.cloud.sap/document-information-extraction/v1/document/jobs.
Then we pulled the actual service key for our SAP Document AI trial instance from the subaccount’s Instances and Subscriptions page:
SAP Document AI, subscribed under the trial subaccount alongside SAP Build Process Automation.
The service key’s credentials show the real backend URL: https://us10-trial.doc.cloud.sap — not https://us10.doc.cloud.sap.
That’s the mismatch. SAP Document AI base URLs follow the pattern https://<tenant-id>.<region>.doc.cloud.sap, and trial-tier URLs are distinguished by the -trial substring appearing in both the tenant and regional domain segments — while standard and premium plans map directly to the plain commercial landscape (us10, eu10, etc.). BPA’s built-in Extract Data activities are resolving the endpoint from the region alone and dropping that -trial qualifier, so on a trial subaccount they always call a host that doesn’t exist for our tenant. That explains the immediate 400, independent of anything about our schema, template, or document.
The Fix: a Destination-Based Extraction Flow
Since the built-in activities resolve the URL internally, there’s no setting inside them to correct it. The workaround is to stop using those activities altogether and call SAP Document AI through an explicit BTP Destination instead, using a set of reusable Document AI activities that take the destination as a parameter rather than assuming a URL.
We built this on top of the approach and reusable automation package shared in Using Document AI Premium in SAP Build Process Automation, which packages a set of Document AI activities (extraction, capabilities, clients, schema lookup, job status, and Premium-specific calls) that go through a destination rather than a hardcoded region URL. The project and its GitHub repo are linked from that post.
- Create a Destination in the BTP Cockpit pointing to the correct trial URL — in our case https://us10-trial.doc.cloud.sap/document-information-extraction/v1 — using OAuth2ClientCredentials authentication with the Document AI service key’s client ID and secret.
The Document_AI destination — Type HTTP, pointing at the correct -trial URL, authenticated via OAuth2ClientCredentials.
- Add the additional properties BPA needs to recognize and use the destination from within a process automation project — these enable it for use as a connector inside BPA and Build Apps.
Additional destination properties: sap.processautomation.enabled, BuildApps.Enabled, and related flags set to true.
- Import the reusable “Document AI service” package from the blog’s GitHub project into your BTP workspace. It ships as a standalone Process Automation package with its own activities.
The imported (package) Document AI service project, with its released and editable versions.
One Limitation: Schema and Template Authoring
The package gives you activities to extract data and query schema/job status, but it doesn’t give you a way to author a schema or a template from inside BPA. That part still has to happen in the standalone SAP Document AI UI, the same way it would for a non-trial setup.
- In the Document AI application, go to Schema Configuration and define your custom schema — header fields (Invoice Number, Dates, Supplier, amounts, etc.) and line item fields (Description, Quantity, Unit Price, Amount).
InvoiceApprovalSchema, defined directly in the Document AI UI — the same field structure used by the approval form in Post 1.
- Create a Template against that schema and validate it against a sample invoice, confirming the extraction confidence per field before relying on it.
InvoiceApprovalTemplate validated against a sample invoice — all header and line item fields extracted correctly.
Once the schema exists, the reusable package’s extraction activity only needs the schema name and the destination — it doesn’t need the template wizard that was failing earlier.
Building the Extraction Automation
With the destination and schema in place, the automation itself is straightforward: collect the PDFs from a folder, and for each one, call the package’s extraction activity.
InvoiceApprovalAutomation — Get File Collection, then a For Each loop calling DocAI – Extract with Schema per file.
- Get File Collection reads every PDF from the source folder.
Get File Collection parameters — folderPath pointing at the invoice PDFs.
- Inside the loop, DocAI – Extract with Schema is called per file, passing the current file and the schema name (InvoiceApprovalSchema) created earlier — this is the activity from the reusable package, going through the destination rather than a hardcoded URL.
DocAI – Extract with Schema — fileToUpload bound to the current loop item, schemaName set to InvoiceApprovalSchema.
Testing Against Multiple Invoices
We ran the flow against three different sample invoices — different suppliers, currencies, and line items — to confirm the extraction held up beyond just the original demo document.
Test Console output — each invoice processed through the loop, with status DONE and the full extracted field set logged per file.
|
|
|
|
|
|
Three sample invoices (EUR and USD, different suppliers and line items) alongside their extracted JSON output — header fields and line items all mapped correctly.
Wrapping Up
With the destination-based package in place, extraction now works reliably against our trial Document AI instance — something the built-in BPA activities simply can’t do on trial until SAP resolves the endpoint resolution on their side. The trade-off is one manual step: schemas and templates still need to be authored in the Document AI UI directly, rather than from within BPA.
Credit to the original SAP Community post for the reusable package and destination pattern that this is built on — our part was tracing the actual root cause via the request URL, defining our own invoice schema, and wiring the extraction loop up as a standalone automation, tested end to end against multiple invoices.
With extraction now solid, the next step is the one this series set out to do from the start: feed this extracted data straight into the InvoiceApprovalProcess from Post 1, so a PDF landing in a folder ends up as an approval task in My Inbox with no manual form-filling at all.
#abap