Test sending, and the Peppol test network
Peppol runs two separate networks. The production network carries real invoices. The test network — the one addressed through the test SML, often called SMK — carries nothing but test traffic. They do not see each other: a participant registered in production is invisible from the test network, and a document sent on the test network never reaches a production inbox.
Which network your account uses
The network is decided by the environment you are logged in to, not by a switch on the invoice.
| Environment | Network | Certificate |
|---|---|---|
| Production portal | Peppol production SML | Production access point certificate |
| Test and stage environments | Peppol test SML (SMK) | Test access point certificate |
This has one consequence worth stating plainly: you cannot send a test-network document from the production portal. There is no "test mode" checkbox, because the certificate and the lookup path differ, not just a flag. If your customer or your integrator asks for a send against the test registry, that has to run on a test environment — ask support to arrange access.
When a customer asks for a test invoice
Most such requests do not actually need the test network. Decide which of these you were asked for:
"Send me one invoice so we can check the format." Send a real invoice with a small amount on the production network, or send the document as a PDF by e-mail from the Sales Invoice screen. Your customer gets the file, and nothing has to be arranged.
"We want to test the integration end to end before go-live." This is the test-network case. It needs a test environment on both sides, and both parties have to be registered on the test network — being registered in production is not enough.
"We want to test our ERP against your API." That is the stage API rather than the Peppol test network. Your integrator can work against the stage environment with its own API key, and no Peppol participant is involved until a document is actually sent.
Registration is per network
A registration is not portable between the two networks. A participant identifier registered on the test network has to be registered again in production before it can receive real invoices, and the reverse is also true. So a successful test does not imply the production route works — the production registration is what makes it work, and you can see its state on Register e-Invoice.
Test-network traffic is not e-invoicing compliance. A French domestic B2B invoice is only compliant once it travels the production route through your plateforme agréée. Test sends prove the integration; they do not discharge the obligation.
What to give support when you request a test
- The participant identifier your counterparty will use, with its scheme.
- The document type and profile they expect — for instance Peppol BIS 3.0.19, or a French CIUS profile.
- Whether they need to send to you, receive from you, or both.
- The date by which the test has to be finished, since a test registration also takes time to activate.