What is Peppol BIS Billing 3.0?
The invoice specification behind the Peppol network: which version is mandatory, how a recipient is addressed, and what the German federal administration expects on top of it.
Specification
Peppol BIS Billing 3.0: one invoice specification for a whole network
Peppol BIS Billing 3.0 is a Core Invoice Usage Specification, a CIUS, of the European standard EN 16931. It is published by OpenPeppol AISBL and it covers two documents, the invoice and the credit note. An instance that conforms to this specification is compliant with EN 16931, so the same file that satisfies a Peppol receiver also satisfies the European core model.
What makes it different from a national specification is the second half of the arrangement. Peppol is also a network with its own addressing, its own access points and its own rules on who may send what to whom. The BIS says what the document must contain, the network says how it travels and how the recipient is found. Both parts have to be right before an invoice arrives.
3.0.21
The release published on 20 May 2026, mandatory to use since 17 August 2026
2 documents
Invoice and credit note, in the UBL syntax, across nine invoicing processes
2 releases a year
May and November, each mandatory about three months after publication
The specification and the network are two different things
A Peppol invoice is not sent to an email address. The sender hands the document to its own access point, the access point looks up where the receiver is registered and delivers it to the receiver's access point, which passes it on. This is the four-corner model, and it is the reason a single registration makes you reachable for every sender in the network.
Through a service provider
A certified service provider operates the access point and registers you in the network. No OpenPeppol membership, no access point of your own, and the same connection can carry other Peppol documents later.
With your own access point
OpenPeppol membership is required and so is the technical operation: setup, certificates, availability, updates twice a year. It makes sense when the volume or the control justifies it.
Four corners today, five corners later
In the model above the document travels between two parties and nobody else sees it. A fifth corner appears when a tax authority joins the exchange and receives the invoice data as it moves. That is what continuous transaction controls mean in practice, and it is the direction European VAT law is taking.
The timetable comes from the VAT in the Digital Age package, adopted on 11 March 2025 and in force since 14 April 2025. Digital reporting for cross-border business-to-business transactions applies from 1 July 2030. By 1 January 2035 member states that run a domestic real-time reporting obligation have to align their systems with the EU model.
What changesA report of the invoice data goes to the tax administration, in addition to the invoice itself reaching the customer. The reporting obligation sits with the parties, not with the network.
What staysThe document, the identifiers and the access points. A fifth corner is added to the picture rather than replacing the four that are there.
Where Germany standsThe German obligation currently covers the invoice itself: receiving since 1 January 2025, issuing from 2027 and 2028. No transaction reporting system is in operation here yet, so the fifth corner is a plan rather than a deadline.
Versions and the release cycle
Peppol publishes two releases a year, in May and in November. Each one is first put to member review, then published, and then becomes mandatory about three months later. The gap is the migration window: during it both the old and the new artefacts are accepted, after the mandatory date only the new ones.
20 May 2026, mandatory since 17 August 2026
3.0.21, the current release
A new optional profile 02, billing with an invoice response, which needs its own registration. The EAS code list was corrected and fourteen unusable codes were removed. Rules PEPPOL-COMMON-R052 and R053 became errors. New warnings for Dutch identifiers, announced as future errors. Validation artefacts UBL and CII 1.3.16 of 10 April 2026.
27 January 2026
3.0.20 hotfix
Added code 0245 for the Slovak tax identification number to the EAS and ICD code lists. Mandatory from 23 February 2026, together with 3.0.20.
24 November 2025
3.0.20
The passage that forbade attaching a PDF copy of the invoice was removed from the compliance section. New Danish identifier rules were introduced as warnings, which is the usual way Peppol phases a rule in.
21 May 2025
3.0.19
French VAT exemption codes added, three German invoice type codes added to the code list, and the Danish CVR rule rewritten with a transition period that ran until the 2026 May release.
Warnings become errors. Peppol introduces most new checks as a warning first and makes them fatal in a later release. An invoice that only produces warnings today can be rejected after the next mandatory date, so the warning list from your validator is worth reading rather than ignoring.
Participant identifiers: how a recipient is addressed
Every participant in the network has an identifier made of a four digit scheme and a value, written as scheme and value separated by a colon. The scheme says what kind of number follows, the value is the number itself. This identifier is what the network routes on, and it is not the same thing as the buyer reference inside the invoice.
0204Peppol-Leitweg-ID. The scheme used to address German public bodies, combined with the recipient's Leitweg-ID.
9930German VAT number. The usual sender identifier for a German company.
0088Global Location Number, the GS1 identifier, widely used in retail and logistics.
0246German Electronic Business Address, added to the code lists with the May 2026 release.
0192, 0184, 9944Norwegian organisation number, Danish CVR, Netherlands VAT. Country specific rules check the format of several of these, and the checks have been tightening with each release.
The identifier appears in the invoice as the endpoint of the seller and of the buyer, with the scheme in an attribute. What a given receiver actually accepts is decided by what that receiver registered in the network, which is why a document can be perfectly valid and still be refused as undeliverable.
What the file looks like
A Peppol BIS Billing document is a UBL invoice or credit note. Two elements at the top of the file decide how it is read: the specification identifier, which says the document follows this BIS, and the business process identifier, which says which process it belongs to. Both are mandatory and both are checked by fatal rules.
UBL invoicepeppol-invoice.xml
Invoice xmlns="...ubl:schema:xsd:Invoice-2"
urn:cen.eu:en16931:2017#compliant#
urn:fdc:peppol.eu:2017:poacc:billing:3.0
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
372026-R150
2026-11-12
991-33333TEST-33
cbc:EndpointID schemeID="0204"991-33333TEST-33
Specification identifierBT-24. It carries no version number. Rule PEPPOL-EN16931-R004 is fatal and it also fails if a version is appended, so a file that names 3.0.21 in this element is rejected.
Business processBT-23. The default is profile 01, plain billing. Profile 02, billing with an invoice response, arrived with the May 2026 release and requires a separate registration before anyone can send it to you.
Endpoint and buyer referenceThe endpoint addresses the network, the buyer reference addresses the recipient's own processing. For a German public body both exist and both carry the Leitweg-ID, in different places.
Three layers of rules decide whether it passes
Validation is not one check but three sets that run on the same file. Knowing which layer rejected an invoice tells you who can change it and who cannot.
01
European business rules
The rules of EN 16931, identified with the BR prefix. They are the same across Europe and they are maintained by CEN, not by Peppol.
02
Peppol rules
Rules with the prefixes PEPPOL-EN16931 and PEPPOL-COMMON, which narrow the European model and check identifiers, code lists and the specification identifier itself.
03
Country specific rules
Rules that only fire when a party is in a particular country, such as the Danish, Dutch, Swedish and German sets. They are governed by a separate OpenPeppol policy, which is why they cannot simply be invented by a single receiver.
Each rule has a severity. A fatal rule stops the document, a warning does not, and the release notes announce which warnings are scheduled to become fatal. Rules are also added and corrected in every release, so the same file can pass in February and fail in September without anyone having touched it.
Invoicing the German federal administration over Peppol
Germany's federal administration runs one submission portal for e-invoices, the OZG-RE, to which all bodies of the direct federal administration are connected. Invoices reach it in four ways: through the Peppol network, by email, by uploading a file in the web interface, or by typing the invoice into the web form. Peppol is the only one of the four that supports machine to machine exchange and mass sending.
Recipient addressThe scheme 0204 followed by the recipient's Leitweg-ID. The Leitweg-ID comes from the contract documents or from the customer.
Sender addressScheme 9930 with the German VAT number, or scheme 0088 with a Global Location Number.
Inside the invoiceThe Leitweg-ID has to be in the invoice as the buyer reference as well. If it is only in the network address, the portal rejects the invoice.
Which formatThe current version of XRechnung as a rule. Other standards are accepted if they meet EN 16931 and the portal's terms of use, for example ZUGFeRD from version 2.1.1 in the XRECHNUNG profile, sent as the plain XML file.
RegistrationRegistration with the portal is free and is required whichever transmission method you use.
Peppol is a channel, not a format. Sending over Peppol does not turn an invoice into an XRechnung, and an XRechnung does not have to travel over Peppol. German public bodies ask for both: the content in the format they require, the delivery through the channel they have registered for.
Peppol BIS Billing, XRechnung and ZUGFeRD
All three are built on the same European core model, which is why the comparison is about scope rather than about data. The question in practice is which set of extra rules your recipient applies and which channel it listens on.
Peppol BIS Billing 3.0A CIUS of EN 16931 maintained by OpenPeppol, tied to a network with its own addressing and its own release calendar. UBL invoice and credit note.
XRechnungA CIUS of EN 16931 maintained by KoSIT for Germany, in two syntaxes, with no network of its own. It is regularly sent over Peppol.
ZUGFeRDA hybrid file: a PDF with the XML inside it. Useful where a human still looks at the document, and the XRECHNUNG profile of it is what German public bodies accept.
A practical consequence: if you already produce a valid XRechnung, the step to Peppol is a delivery question, not a data question. If you produce Peppol BIS Billing for other European customers, the German rules are an additional layer on top, not a different document.
PINT and what comes next
Peppol has a second family of billing specifications, PINT, built so that regions outside Europe can define their own billing rules on a shared base. PINT BIS Billing was published on 8 June 2026 and is mandatory from 7 September 2026, together with its regional versions, among them PINT BIS Billing EU for the European Union.
Both families are currently published side by side, and OpenPeppol lists them together in its post-award documentation with their own publication and mandatory dates. Peppol BIS Billing 3.0 remains the published EU specification with its own release cycle, so the sensible reading is that an implementation has to follow the dates in that table rather than any announced end date for the older family.
If your service provider handles the specification versions for you, this is their work rather than yours. If you operate your own access point, the dates in the OpenPeppol documentation table are the ones to watch.
Validation
Peppol publishes validation artefacts for UBL and CII with every release, and they are versioned separately from the BIS itself: the May 2026 release carries artefacts 1.3.16, published on 10 April 2026, with code lists from 6 March 2026. Checking against the right artefact version is as important as checking at all.
A file can fail for three quite different reasons, and they need different fixes: the XML is not schema valid, a business rule is broken, or the document is valid but the recipient is not registered for what you sent. Only the first two are visible in a validator.
Retention
For a German business the structured file is the invoice, and it is the structured file that has to be kept. The retention period is eight years under section 14b of the German VAT Act, and the document has to stay readable and unchanged for that whole period. A transmission log from an access point is evidence of delivery, not a substitute for the invoice itself.
How we help
Invoice Portal connects you to the Peppol network and takes care of the parts that change twice a year, so that your own system keeps producing the same thing.
ConnectionSending and receiving over Peppol without you operating an access point, with your participant identifier registered for the documents you actually want to receive.
FormatsPeppol BIS Billing, XRechnung and ZUGFeRD from the same data, so a recipient that asks for a different format does not become a project.
Validation before sendingDocuments checked against the artefact version that is mandatory at that moment, with the rule, the element and its position in the report.
Release changesThe twice yearly updates are applied on our side. You see them as a changed rule in a report, not as a migration.
Frequent questions
Is a Peppol invoice the same as an XRechnung?
No. Both are usage specifications of EN 16931, but they are maintained by different bodies and they narrow the standard in different places. An XRechnung is frequently delivered over the Peppol network, which is where the confusion comes from: one is the document, the other is the way it travels.
Do I have to become an OpenPeppol member?
Only if you want to run your own access point. Going through a certified service provider requires no membership and no access point of your own, and it is the usual route for a company that simply wants to send and receive invoices.
Which version do I have to use right now?
Release 3.0.21, which was published on 20 May 2026 and has been mandatory since 17 August 2026. The version number does not go into the document: the specification identifier names the BIS without a version, and writing a version into it is a fatal error.
Can I send the CII syntax instead of UBL?
Peppol publishes validation artefacts for both syntaxes and the BIS has an annex on the Cross Industry Invoice, but what you may send is decided by what the recipient has registered in the network. UBL is the syntax the specification is written around, and it is what you should assume unless the recipient says otherwise.
My invoice is valid but it was not delivered. What now?
Validity and reachability are separate. Check that the participant identifier is the one the recipient uses, that the scheme in front of it is right, and that the recipient is registered for the document type and the profile you sent. Profile 02, billing with a response, in particular needs its own registration on the receiving side.
Does Peppol replace the e-invoicing obligation in Germany?
No. The German rules say what an invoice must be and from when; they do not prescribe a channel. Peppol is one way to meet them, email with an attached XML is another. What Peppol adds is automated delivery and a directory in which recipients can be found.
Resources
OpenPeppol: Peppol BIS Billing 3.0The specification itself, with the syntax tree, the code lists and the rule descriptions OpenPeppol: release notes
Every release with its publication and mandatory date and the rules that changed OpenPeppol: post award documentation
The table of published specifications, including PINT BIS Billing EU, with publication and mandatory dates Federal administration: transmission over Peppol
Official guidance on the OZG-RE portal, the 0204 addressing and the accepted formats European Commission: VAT in the Digital Age
The package, the legal acts and the dates from 2030 to 2035 OpenPeppol: certified service providers
The official list of providers that may operate an access point in the network
Send and receive invoices over Peppol
Tell us who you need to reach and we set up the connection, the identifier and the format.
- Peppol BIS Billing, XRechnung and ZUGFeRD from the same data
- Your participant identifier registered for what you want to receive
- Twice yearly release changes handled on our side
Check an invoice first
Free and unlimited · the file stays in your browser session
What happens next
- 01You send the form, we reply within one business day.
- 02A short call, a test account and a first invoice checked on your own data.
Prefer to talk directly? info@invoice-portal.de · +49 561 56014568
Send your request
Your contact details
Let us start with the basics.
Your situation
Three questions, so the first answer is a useful one.
Almost done
Add a message and send it.
