Self-Billing implementieren: NLCIUS-Variante und BIS Self-Billing 3.0, Capabilities prüfen.
Als Käufer können Sie über die PSB API eine Self-Billing-Rechnung im Namen Ihres Lieferanten erstellen und versenden. Dieser Artikel beschreibt Schritt für Schritt, wie Sie dies für beide Varianten tun: die NLCIUS-Variante und Peppol BIS Self-Billing 3.0.
Prüfen Sie immer zuerst, ob der Lieferant das gewünschte Self-Billing-Format empfangen kann:
GET /api/v1/queryRecipientParty?identifier={schemeID}:{LieferantHR} HTTP/1.1
Host: psb.econnect.eu
Authorization: Bearer {access_token}
Suchen Sie in der Antwort nach dem unterstützten Profil. Bei NLCIUS ist dies das Standard-Rechnungsprofil; bei BIS Self-Billing 3.0 das spezifische Self-Billing-Profil.
Dies ist die einfachste Möglichkeit, eine Self-Billing-Rechnung zu versenden. Sie verwenden dieselbe CustomizationID und ProfileID wie bei einer regulären NLCIUS-Rechnung, ändern aber den InvoiceTypeCode auf 389:
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
<CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0</CustomizationID>
<ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ProfileID>
<ID>SB-2026-001</ID>
<IssueDate>2026-03-05</IssueDate>
<InvoiceTypeCode>389</InvoiceTypeCode>
<!-- AccountingSupplierParty = der Lieferant (Empfänger der Rechnung) -->
<AccountingSupplierParty>
<Party>
<EndpointID schemeID="0106">87654321</EndpointID>
<PartyName><Name>Lieferant B.V.</Name></PartyName>
...
</Party>
</AccountingSupplierParty>
<!-- AccountingCustomerParty = der Käufer (Ersteller der Rechnung) -->
<AccountingCustomerParty>
<Party>
<EndpointID schemeID="0106">12345678</EndpointID>
<PartyName><Name>Käufer B.V.</Name></PartyName>
...
</Party>
</AccountingCustomerParty>
...
</Invoice>
Versenden Sie das Dokument über den SalesInvoice-Endpoint:
POST /api/v1/{partyId}/salesInvoice/send HTTP/1.1
Host: psb.econnect.eu
Authorization: Bearer {access_token}
Content-Type: application/xml
X-EConnect-DocumentId: {uuid}
Der PSB erkennt automatisch den InvoiceTypeCode 389 und leitet das Dokument als Self-Billing-Rechnung an den Lieferanten weiter.
Tipp: Für eine Self-Billing-Gutschrift verwenden Sie InvoiceTypeCode
261statt389.
Bei dieser Variante verwenden Sie das spezifische Self-Billing-Profil mit eigenen Identifiern:
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
<CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0</CustomizationID>
<ProfileID>urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0</ProfileID>
<ID>SB-2026-001</ID>
<IssueDate>2026-03-05</IssueDate>
<InvoiceTypeCode>389</InvoiceTypeCode>
<AccountingSupplierParty>
<Party>
<EndpointID schemeID="0106">87654321</EndpointID>
<PartyName><Name>Lieferant B.V.</Name></PartyName>
...
</Party>
</AccountingSupplierParty>
<AccountingCustomerParty>
<Party>
<EndpointID schemeID="0106">12345678</EndpointID>
<PartyName><Name>Käufer B.V.</Name></PartyName>
...
</Party>
</AccountingCustomerParty>
...
</Invoice>
Versenden Sie BIS Self-Billing-Dokumente über den Generic-Endpoint:
POST /api/v1/{partyId}/generic/send HTTP/1.1
Host: psb.econnect.eu
Authorization: Bearer {access_token}
Content-Type: application/xml
X-EConnect-DocumentId: {uuid}
Der PSB erkennt das Self-Billing-Profil anhand der CustomizationID und leitet das Dokument an den Lieferanten weiter, sofern dieser für das BIS Self-Billing 3.0 Profil registriert ist.
Achten Sie auf den Unterschied in den Parteirollen beim Self-Billing. Dies ist eine häufige Quelle von Verwirrung:
AccountingSupplierPartyAccountingCustomerPartyDie AccountingSupplierParty ist immer der Lieferant, auch wenn der Käufer die Rechnung erstellt. Der Käufer trägt seine eigenen Daten bei AccountingCustomerParty ein.
Verwenden Sie immer den X-EConnect-DocumentId-Header, um doppelte Sendungen zu vermeiden. Die Regeln sind identisch mit denen für reguläre Rechnungen: mindestens 6 Zeichen, vorzugsweise eine UUID, niemals die Rechnungsnummer. Mehr dazu im Artikel Idempotency.
Häufige Fehler beim Self-Billing:
389 oder 261 istqueryRecipientParty; bei BIS Self-Billing muss der Lieferant separat registriert seinNach dem Versand erhalten Sie dieselben Webhook-Events wie bei regulären Rechnungen:
InvoiceSent bei erfolgreicher ZustellungInvoiceSentRetry bei einem neuen Versuch (max. 8 Retries)InvoiceSentError wenn die Zustellung endgültig fehlschlägtFür NLCIUS mit InvoiceTypeCode 389 oder 261 und den üblichen NLCIUS-Profilen senden Sie an POST /api/v1/{partyId}/salesInvoice/send mit XML-Body und optional X-EConnect-DocumentId. Für BIS Self-Billing 3.0 mit der zugehörigen CustomizationID und ProfileID verwenden Sie POST /api/v1/{partyId}/generic/send; die PSB erkennt das Profil aus dem Dokument.
AccountingSupplierParty ist immer der Lieferant (beim Self-Billing die Partei, die die Rechnung "empfängt"), und AccountingCustomerParty ist der Käufer, der das Dokument im Namen des Lieferanten erstellt und versendet. Diese Vertauschung gegenüber einer regulären Verkaufsrechnung ist ein häufiger Implementierungsfehler.
Verwenden Sie dieselben Idempotency-Regeln wie bei regulären Rechnungen: Senden Sie X-EConnect-DocumentId mit einer UUID, keine Rechnungsnummer. Payloads größer als circa 24 MB (einschließlich Overhead) werden vom Webserver abgelehnt; reduzieren Sie eingebettete base64-PDFs oder teilen Sie die Lieferung auf, wobei circa 33% Overhead durch base64 einzurechnen ist.
Möchten Sie das Dokument vor dem Versand validieren? Verwenden Sie die Validate API, um Ihre Self-Billing-Rechnung zu prüfen, ohne sie tatsächlich zu versenden.
In der API ausprobieren