Sending a compliant e-invoice from SAP means four things: getting the billing document out of SAP, mapping it to UBL 2.1, validating it against EN 16931 and the Peppol BIS 3.0 or PINT profile for the receiving country, and transmitting it over AS4 through a certified Access Point. How you do the first step decides how long the project takes.
With an API-based integration
What it does not need
Read-only access. GoRoute never writes back to SAP.
Every SAP Peppol integration follows the same four stages, whichever extraction method you choose. The stages are fixed by the standards — EN 16931 defines the semantic model, UBL 2.1 the syntax, Schematron the validation rules, and AS4 the transport. What varies between projects is only how the document leaves SAP in the first stage.
A push design has SAP send documents out through an SM59 destination, which needs a change request and a transport. A pull design reads them over OData with a communication user. Both are valid; the second avoids a development cycle.
A billing document carries SoldToParty and
CompanyCode as identifiers, not as parties. EN 16931
requires each party's legal name, address and tax identifier, so business partner
data must be resolved and complete — the most common cause of failed validation.
SAP publishes a public API sandbox on the Business Accelerator Hub exposing the same services and payload shapes as a live system. A proof of concept built there transfers to production unchanged.
Facing a mandate deadline in one or more countries, with no appetite for an ABAP project.
Delivering compliance workstreams who need the network side handled by a certified provider.
Running several company codes across jurisdictions from one SAP instance.
Who own the mandate but cannot commission SAP development to meet it.
The extraction path differs by product; everything downstream of the canonical invoice model is identical.
| SAP product | How documents are read | Status |
|---|---|---|
| S/4HANA Cloud (public & private) | API_BILLING_DOCUMENT_SRV over OData |
Direct |
| S/4HANA on-premise | Same OData service, communication user | Direct |
| SAP ECC 6.0 | IDoc INVOIC or extract to the canonical model | Supported |
| Business ByDesign | Web service extraction to the canonical model | Supported |
| SAP Ariba | Documents submitted to the GoRoute REST API | Supported |
Service and payload shapes are documented on the SAP Business Accelerator Hub, and communication scenarios on SAP Help Portal.
Six capabilities, required by the standards rather than by any one vendor. Any solution you evaluate — built in-house or bought — has to cover all six.
Billing documents and their items, filtered by company code, date range or document type.
Legal names, addresses and tax identifiers pulled from API_BUSINESS_PARTNER and cached.
Canonical model to UBL 2.1 Invoice or CreditNote with the correct document type identifier.
XSD, business rules, codelists and Schematron for the target profile. Failures stop before transmission.
SMP lookup for the recipient, then AS4 delivery to their Access Point with signed receipts.
Per-document status, validation reports and webhook callbacks on delivery or failure.
Where SAP already emits a finished UBL document — via the eDocument Framework or an existing middleware mapping — extraction is unnecessary and the document can be posted straight to an Access Point for validation and transmission.
curl -X POST https://app.goroute.ai/peppol-api/documents \
-H "Authorization: Bearer $GOROUTE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"sender_id": "0088:7300010000001",
"receiver_id": "0248:OM1100099001",
"document_type": "invoice",
"document": "<Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\">...</Invoice>"
}'Full reference, webhooks and SDKs at docs.goroute.ai, or see Peppol API integration and developer resources.
Four steps. The first is the only one that touches your SAP system.
Activate the SAP_COM_0120 communication scenario and create a user with
read access to API_BILLING_DOCUMENT_SRV and
API_BUSINESS_PARTNER. Read access only — this is the whole
SAP-side change.
In the dashboard, open Connectors → SAP S/4HANA, enter your OData base URL and the communication user's credentials, and test the connection before saving.
Your company is published on the SMP so trading partners can discover you. GoRoute performs the registration as a certified provider — see SMP service.
Pick a document, review the generated UBL and its validation report, then send. Delivery status and the recipient's signed receipt come back to the dashboard and to your webhook.
Becoming your own Peppol Access Point is a legitimate choice. It is worth knowing what it carries before choosing it.
| Responsibility | Build in-house | With GoRoute |
|---|---|---|
| Peppol AP accreditation | Apply, audit, maintain annually | Covered — POP000991 |
| AS4 certificates | Procure, rotate, monitor expiry | Managed |
| SML / SMP enrolment | Operate your own SMP | Included |
| Schematron rule updates | Track every release, per jurisdiction | Continuous |
| New country mandates | A project each time | A configuration change |
| SAP-side development | Typically ABAP plus a transport | A communication user |
Considering the alternative properly? Read how to choose a Peppol Access Point and hosted Peppol infrastructure.
The SAP extraction is identical everywhere. What changes per country is the profile and the Schematron rule set the invoice is validated against.
POP000991
Peppol Certified Access Point and SMP provider
ISO 27001
Information security management
ISO 22301
Business continuity management
OTA accredited
Oman Tax Authority service provider
Standards referenced on this page are published by OpenPeppol, OASIS UBL 2.1, and CEN EN 16931.
Which profile your SAP invoices are validated against, and why it differs by country.
The master-data problems that cause most first-run failures from an ERP.
What to ask a provider before you commit an ERP integration to them.
Which countries oblige your SAP entities to file electronically, and when.
What German B2B e-invoicing expects from an SAP-generated document.
What finance teams need ready before the first document is sent.
Other ERP connectors: Oracle · Odoo · TallyPrime · Sage · Zoho · Stripe · Microsoft Dynamics
The questions SAP and finance teams actually ask on the first call.
API_BILLING_DOCUMENT_SRV OData service, an outbound IDoc, or the SAP eDocument Framework. Second it is mapped to UBL 2.1 following the EN 16931 semantic model, with trading parties resolved from business partner data. Third it is validated against the Peppol BIS Billing 3.0 or PINT Schematron rules for the receiving country. Fourth it is transmitted over AS4 through a certified Peppol Access Point. Only the first stage differs between projects.
API_BILLING_DOCUMENT_SRV and API_BUSINESS_PARTNER, exposed through communication scenario SAP_COM_0120. Write access is not required to send an invoice. A billing document carries SoldToParty and CompanyCode as identifiers rather than as full parties, which is why partner data must be readable separately.
We will read a billing document out of an S/4HANA system, show you the UBL it produces and the validation report, and send it. Bring your own system or use the sandbox.