Peppol has been designed to make the exchange of business documents as simple as sending an e-mail. But that comes with a few attention points. In this blog, we remind briefly of what the Peppol 4-corner model means for testing and how SAP customers using SAP Document Compliance, cloud edition (formerly known as invoicing option for Peppol) can perform end-to-end testing.
The main thing about Peppol is that it is a 4-corner model. For each invoice sent, the network relies on the Peppol ID of the invoice receiver (corner 4) to determine the provider and get the corresponding communication details (corner 3)[1].
Receiver IDs are maintained in the backend system of the invoice sender (corner 1), more precisely in the master data for customers or business partners[2]. In the Peppol message, the Receiver ID is mapped to two places: the Business Document Header and the Invoice body. Only the Receiver ID in the Business Document Header is used by the Peppol infrastructure for routing.
Both Sender and Receiver IDs are checked for compliance to Peppol specifications. That means that the structure of e.g. a German VAT ID will be checked to comply with a length of 11 digits (e.g. DE999999999)[3].
All that aims at making the sending of electronic invoices as easy (actually easier) than sending an e-mail. Consequently, like an e-mail test server would send your message to the real e-mail recipient, a Peppol test message will be processed to the final receiver of that ID. At many SAP users, Test and/or QA backend systems are copied from production. At the moment of testing, your partner master data can consequently hold real world IDs: VAT IDs, LeitwegIDs, KVKs, etc. - a dangerous mix.
The approach proposed by SAP Document Compliance is to select for testing only partners that have registered Peppol test IDs. They can mostly be identified in the Peppol repositories (SMP) by the suffix _TEST.
The SAP Peppol test environment will take care of modifying the Peppol ID in the Business Document Header (e.g. from VAT ID DE999999999 to DE999999999_TEST). It will then check if such a partner is registered in Peppol directories. If yes, the invoice is sent to the Receiver. If not, the invoice will (still) go out to the then potentially productive Receiver. The setup is not ideal – agreed – but it is also necessary as you might want to send to a test partner without _TEST prefix. The setup has to handle both cases.
With that approach, you can use your customer master data (stored at corner 1), the ID structure checks will be successful (corner 2 and 3) and the Receiver can process your test invoice in their test system without changing their master data (corner 4).
Two main options to find test Receivers.
To avoid sending to unwanted Receivers, be protective of customers activated for sending. In table EDOEUBUPAV, you can control activated receivers in your test environment[7].
For further information on testing, see the section Testing Best Practices in the Peppol service documentation of SAP Document Compliance, cloud edition and the aforementioned blog on testing with yourself.
For information on the German LeitwegID, see the blog All you wanted to know about the identification of public organizations for electronic invoicing in .... For other Peppol identifiers, check Peppol IDs in the context of SAP Document Compliance. For testing ZUGFeRD, see the blog How to change E-Mail during test phase? For details on XRechnung and ZUGFeRD, see the blog series All you wanted to know about the electronic invoice in Germany (also in German). For information on SAP Document Compliance go to the related Community page.
This blog has been written with the help of venkatjs.01, Felipe Velloso Alves, ga.nagy and eleonora.vidal. Thank you too to ganeshbabu.n for feedback and corrections.
[1] To simplify, we use the word “invoice” as a proxy for any type of document exchanged through the Peppol network using Peppol IDs.
[2] For details refer to the corresponding documentations. For on-premise backend systems, see Master data section in the latest documentation attached to note 2690949 (or alternatively SAP S/4HANA, SAP ECC). For S/4HANA Cloud, see documentation section Master data.
[3] For details on what IDs are supported by the Peppol network, see Peppol documentation https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/.
[4] Needless to say that you should only do that for IDs owned by your organization as any use of another ID could be interpreted as misuse by the actual owner. NEVER ever register e.g. VAT IDs of your customers in the Peppol infrastructure!
[5] See Customizing section, Activate Source Document Types per Company Code (EDOCOMPANYACTIV ) and Define Interface Type per eDocument Type (EDOINTTYPEV).
[6] The Url is https://jam4.sapjam.com/discussions/e17Uiqw07mrwAnCCJka05f. If needed, please request access to the forum by sending an e-mail to gsjam@sap.com for SAP Document Compliance – Germany. Specific group terms apply. Thank you to all SAP customers participating.
[7] View EDOEUBUPAV in transaction SM30.
Peppol in brief
The main thing about Peppol is that it is a 4-corner model. For each invoice sent, the network relies on the Peppol ID of the invoice receiver (corner 4) to determine the provider and get the corresponding communication details (corner 3)[1].
Illustration: the 4-corner model, here with both sender and receiver using SAP Document Compliance.
Receiver IDs are maintained in the backend system of the invoice sender (corner 1), more precisely in the master data for customers or business partners[2]. In the Peppol message, the Receiver ID is mapped to two places: the Business Document Header and the Invoice body. Only the Receiver ID in the Business Document Header is used by the Peppol infrastructure for routing.
Illustration: positions of the Sender and Receiver IDs in a Peppol message (simplified view).
Both Sender and Receiver IDs are checked for compliance to Peppol specifications. That means that the structure of e.g. a German VAT ID will be checked to comply with a length of 11 digits (e.g. DE999999999)[3].
All that aims at making the sending of electronic invoices as easy (actually easier) than sending an e-mail. Consequently, like an e-mail test server would send your message to the real e-mail recipient, a Peppol test message will be processed to the final receiver of that ID. At many SAP users, Test and/or QA backend systems are copied from production. At the moment of testing, your partner master data can consequently hold real world IDs: VAT IDs, LeitwegIDs, KVKs, etc. - a dangerous mix.
How can you avoid sending invoices to the production of your business partners?
The approach proposed by SAP Document Compliance is to select for testing only partners that have registered Peppol test IDs. They can mostly be identified in the Peppol repositories (SMP) by the suffix _TEST.
The SAP Peppol test environment will take care of modifying the Peppol ID in the Business Document Header (e.g. from VAT ID DE999999999 to DE999999999_TEST). It will then check if such a partner is registered in Peppol directories. If yes, the invoice is sent to the Receiver. If not, the invoice will (still) go out to the then potentially productive Receiver. The setup is not ideal – agreed – but it is also necessary as you might want to send to a test partner without _TEST prefix. The setup has to handle both cases.
Illustration: ID replacement logic of the test Peppol environment of SAP Document Compliance.
With that approach, you can use your customer master data (stored at corner 1), the ID structure checks will be successful (corner 2 and 3) and the Receiver can process your test invoice in their test system without changing their master data (corner 4).
Two main options to find test Receivers.
- For first test iterations, it’s advisable to test with your own participant ID, so to send to yourself. You can register test Receivers with IDs owned by your organization and maintain them as Receiver in your customer or business partner master data[4]. For that reason, during the customizing of SAP Document Compliance, we recommend that you activate Peppol inbound invoices even if you only plan to go live with outbound invoices[5]. Doing so, you might receive test invoices from other business partners of your organization, but due to the Peppol ID ending with _TEST they shall not be in a position to expect that you process them productively. For more details on how to test with yourself, see this blog by d.cotelea.
- You can use the test IDs of your customers or of other business partners who preferably agreed with that. Be mindful in your selection as your test system might contain information that you do not want to share unwantedly with test partners (e.g. prices, rebates, etc.). In the customer Jam for SAP Document Compliance Germany, you can find a forum thread for exchanging such test IDs[6].
To avoid sending to unwanted Receivers, be protective of customers activated for sending. In table EDOEUBUPAV, you can control activated receivers in your test environment[7].
For further information on testing, see the section Testing Best Practices in the Peppol service documentation of SAP Document Compliance, cloud edition and the aforementioned blog on testing with yourself.
For information on the German LeitwegID, see the blog All you wanted to know about the identification of public organizations for electronic invoicing in .... For other Peppol identifiers, check Peppol IDs in the context of SAP Document Compliance. For testing ZUGFeRD, see the blog How to change E-Mail during test phase? For details on XRechnung and ZUGFeRD, see the blog series All you wanted to know about the electronic invoice in Germany (also in German). For information on SAP Document Compliance go to the related Community page.
This blog has been written with the help of venkatjs.01, Felipe Velloso Alves, ga.nagy and eleonora.vidal. Thank you too to ganeshbabu.n for feedback and corrections.
[1] To simplify, we use the word “invoice” as a proxy for any type of document exchanged through the Peppol network using Peppol IDs.
[2] For details refer to the corresponding documentations. For on-premise backend systems, see Master data section in the latest documentation attached to note 2690949 (or alternatively SAP S/4HANA, SAP ECC). For S/4HANA Cloud, see documentation section Master data.
[3] For details on what IDs are supported by the Peppol network, see Peppol documentation https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/.
[4] Needless to say that you should only do that for IDs owned by your organization as any use of another ID could be interpreted as misuse by the actual owner. NEVER ever register e.g. VAT IDs of your customers in the Peppol infrastructure!
[5] See Customizing section, Activate Source Document Types per Company Code (EDOCOMPANYACTIV ) and Define Interface Type per eDocument Type (EDOINTTYPEV).
[6] The Url is https://jam4.sapjam.com/discussions/e17Uiqw07mrwAnCCJka05f. If needed, please request access to the forum by sending an e-mail to gsjam@sap.com for SAP Document Compliance – Germany. Specific group terms apply. Thank you to all SAP customers participating.
[7] View EDOEUBUPAV in transaction SM30.
- SAP Managed Tags:
