Setting up e-invoicing (IRN) in SAP — the eDocument-to-GSP configuration most implementations get wrong

SAP's own documentation for wiring e-invoicing to a GST Suvidha Provider runs to over twenty pages of certificates, credential aliases and case-sensitive field names — and it comes in two versions, for two different SAP cloud environments, that agree on the certificate requirements and diverge in two other places — where the integration flows come from, and which authentication method SAP recommends. Most of what goes wrong afterwards traces back to one of those pages, not to the GSP or the government portal.

Two SAP guides, and a certificate step both require but older walkthroughs miss

SAP's e-invoicing solution for India doesn't call the government's Invoice Registration Portal (IRP) directly. It routes every invoice from SAP ERP or SAP S/4HANA through SAP's own integration middleware to a GST Suvidha Provider (GSP), which does the actual IRP round trip and hands back the IRN and QR code. SAP publishes two parallel setup guides for that middleware layer depending on which SAP cloud environment you're on — SAP Cloud Integration for the older Neo environment, and SAP Integration Suite for Cloud Foundry / SAP BTP — and the two are close enough to invite copy-paste from the wrong one.

Almost every step matches on both guides: import the GSP's SSL certificate, deploy IRP credentials per GSTIN, deploy the IRP Public Key Certificate, deploy a Router-plus-GSP integration flow pair, set up authentication — and, on both, deploy an IRP Signed Content Verification Public Key Certificate, used to validate the SignedQRCode and SignedInvoice fields the IRP returns. This step is not a Cloud-Foundry-only addition: SAP's Neo guide requires it too, under the alias jwtcert and the parameter irpsignver_pkalias. What makes it easy to miss is timing, not environment — it was added to both guides on the same date, 23 September 2020 (Neo v1.3; Cloud Foundry / Integration Suite v1.1). A team working from an older, pre-September-2020 walkthrough, or a GSP's own generic template that predates that revision, can complete every step it lists and never learn this one exists on either platform. SAP's guides don't describe what happens next, but on the documented sequence the certificate is deployed to the keystore independently of the integration flow, so nothing forces it to be present at deploy time — it only matters the first time SAP tries to validate a signed response and has nothing to check it against. Two other things genuinely differ by environment, covered below where they come up: where the integration flows themselves come from, and which authentication method SAP recommends.

What you need from your GSP before you open SAP

Before touching either integration tenant, SAP's prerequisites largely overlap between the two guides:

• The SAP Notes for the eInvoice Solution installed in your test and production systems (master note 2884058).
• The tenant itself already provisioned — initial setup of SAP Cloud Integration (Neo) or SAP Integration Suite (Cloud Foundry) completed, with its own Web UI URL in hand.
• From your chosen GSP: its integration/setup manual, the SSL certificates for the handshake, the IRP Public Key Certificate, and the IRP Signed Content Verification Public Key Certificate — required on both the Neo and Cloud Foundry paths — all as Base-64 encoded X.509 (.CER) files. Sandbox credentials come from the GSP directly; production credentials come from registering on the IRP itself.
• Where the two guides diverge: on Cloud Foundry, two integration-flow packages as .zip files from the GSP — a GSP Integration Flow specific to that provider, and a Router Integration Flow that directs eInvoice requests from SAP to the right GSP flow. On Neo, there's nothing to request from the GSP for this part: you instead copy SAP's own "ERP Integration with GST Suvidha Provider for India e-Invoice" content package from the tenant's Discover catalog and adapt its GSP Integration Template yourself — though an SAP-certified GSP will still hand you a pre-built flow and its own setup documentation for that template (SAP Note 2889709 lists the certified GSPs).

Registration on the IRP itself is a separate step from anything inside SAP. If the business is already calling the e-Way Bill system via API, those same API credentials carry over for e-invoicing. If not, someone has to register the GSTIN in the e-invoice system on the IRP and log in with those credentials to get an API username and password before SAP has anything to authenticate with.

The configuration steps — and where they're actually skipped

Both SAP guides run through the same sequence, expressed here in the order SAP's own documentation gives it:

1. Import the GSP's SSL certificate into the integration tenant's keystore, then run SAP's built-in TLS connectivity test against the GSP's base URL before configuring anything downstream. If this step is wrong, everything after it will look configured and still fail.
2. Deploy IRP user credentials per GSTIN into the tenant's Security Material / User Credentials store. The Name field is the GSTIN itself, or the GSTIN with an _einv suffix when the credential is dedicated to e-invoicing rather than shared with e-way bill calls — and SAP's own documentation flags the suffix as case-sensitive. SAP's guides don't describe what a mismatch does, but nothing in the documented flow points to a lookup diagnostic for it — the practical risk is that the integration flow simply can't find the credential it's looking for.
3. Deploy the IRP Public Key Certificate to the keystore under the alias irpcert, and the IRP Signed Content Verification Public Key Certificate under the alias jwtcert — required on both the Neo and Cloud Foundry guides. This is the step described above that older, pre-September-2020 walkthroughs never mention.
4. Deploy the Router and GSP integration flows — from the GSP's .zip files on Cloud Foundry, or the copied-and-adapted SAP template on Neo. In the GSP flow's connection settings, the GSP name has to match — case-sensitive — the GSP name entered on the SAP side in the EDOINEINVGSPV view (the eDocument India e-Invoice Service Provider table, maintained via transaction SM30). SAP's guides don't say what happens on a mismatch either; the practical risk is the same shape as the credential name above — the router has nowhere correct to send the request.
5. Configure the flow's parameters: irppkalias and irpsignver_pkalias (both paths) point at the certificate aliases just deployed; userGSTIN_publicAPI supplies the GSTIN used for GSP-side lookups like getGSTIN and syncGSTIN. Every other endpoint path — authenticate, generate IRN, cancel IRN, generate or cancel an e-way bill from the IRN — comes from the specific GSP's own integration manual, not from SAP's generic template; SAP's guide is explicit that it cannot supply these.
6. Set up authentication for the inbound call from SAP into the integration tenant — the second point where the two guides part ways. On Neo, SAP's stated recommendation is client-certificate authentication with certificate-to-user mapping, where the certificate is mapped to a tenant user whose authorizations then apply. On Cloud Foundry, set up basic authentication via a service instance and service key, or client-certificate authentication using the client_x509 grant type with the PEM-encoded client certificate embedded in the service key. Either environment, the certificate presented has to be signed by an SAP-approved Certificate Authority; a self-signed certificate is rejected outright.
7. Deploy, confirm Started status for both flows under Manage Integration Content, then copy the resulting endpoint URL into SOA Manager on the SAP side. Nothing earlier in the sequence flags that this last step still has to happen — it's the one most often left for "later" and then forgotten.

Reading the result — and what a silent failure actually costs

Once invoices are flowing, SAP surfaces the outcome in the eDocument Cockpit or the Manage Electronic Documents app: filter to the India eInvoice process, and the Status column shows where each document sits. The status that confirms success is specific — eInvoice Generated, set only once the IRP has actually generated the eInvoice and returned an IRN. Anything else parked in that queue needs a look, not an assumption that it will clear itself. SAP's own support knowledge base (KBA 2872365) separately documents a manual IRN process for use when the automated GSP integration isn't in play.

What an eDocument stuck before "eInvoice Generated" actually costs is not cosmetic. Under Rule 48(4) of the CGST Rules, a registered person — other than a government department, a local authority, an SEZ unit, an insurer, a banking company or financial institution (including an NBFC), a goods transport agency, a passenger transport service, or a multiplex-cinema admission supplier — whose aggregate turnover has exceeded ₹5 crore in any preceding financial year from 2017-18 onwards must generate e-invoices for its B2B supplies and exports (Notification 13/2020-Central Tax dated 21 March 2020, as amended by Notification 10/2023-Central Tax w.e.f. 1 August 2023); Rule 48(5) is explicit that an invoice issued any other way "shall not be treated as an invoice" at all. Per GSTN's advisory on auto-population of e-invoice details into GSTR-1 (30 November 2020), documents that did reach the IRP auto-populate into the corresponding tables — B2B into 4A, reverse charge into 4B, exports into 6A, credit/debit notes into 9B; GSTN publishes no auto-population latency figure, and secondary sources reporting anywhere from T+2 to T+3 days aren't traceable to any GSTN instrument. An eDocument that never reaches "eInvoice Generated" doesn't just ship without a QR code — under Rule 48(5), that document "shall not be treated as an invoice" at all, and it is that failure, not the eDocument status by itself, that then trips Section 16(2)(a) for the buyer: no valid tax invoice, no credit, regardless of what happens next in GSTR-1. GSTN's advisory (para 11) also requires suppliers to separately key in GSTR-1 entries for supplies not auto-populated from e-invoices, so a stuck eDocument does not necessarily mean the invoice never reaches the buyer's GSTR-2B (Section 16(2)(aa), read with Rule 36(4)(b) and Rule 60(7), which is what actually names GSTR-2B) at all — and arguably that manual route is the worse case, not the safer one: the credit can then look available in 2B while resting on a document that, under Rule 48(5), was never legally an invoice, a mismatch a return filing won't surface on its own. And since 1 April 2025 (GSTN advisory 5 November 2024, reiterated on the IRP 27 March 2025), a taxpayer with aggregate turnover of ₹10 crore or more cannot report an invoice, credit note or debit note on the IRP more than 30 days after its document date — GSTN states there is no such reporting restriction below ₹10 crore "as of now", and this is IRP validation resting on no rule or notification, configurable without further notice (position as of August 2026). A configuration fault caught late, on an invoice above that threshold that's aged past the window, doesn't mean a delayed IRN — it means that invoice can never get one.

That is exactly why checking every SAP-side eDocument against what actually shows up in the GSTR-1 auto-population, invoice by invoice, across every GSTIN and every GSP in play, is painful to do manually — a queue that clears itself most days and silently doesn't on the one day it matters.

How Recoup fits

Recoup doesn't replace this configuration or generate IRNs on your behalf — it sits downstream of it. It reconciles what your books show as sold or bought against what the GST portal actually reflects, checking that every vendor invoice you claim credit on carries a valid IRN before you book it, and, on your own outward side, that everything SAP marked as pushed for e-invoicing genuinely reached GSTR-1 rather than sitting stuck in the eDocument queue. The setup above gets the pipe connected once. Confirming it stays honest every filing period is the reconciliation.

Related guides