Self-Billing-Rechnung versenden über die API

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.

Vorab: Capabilities prüfen

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.

Variante 1: NLCIUS (vereinfacht)

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 261 statt 389.

Variante 2: BIS Self-Billing 3.0

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.

Unterschied in den Rollen

Achten Sie auf den Unterschied in den Parteirollen beim Self-Billing. Dies ist eine häufige Quelle von Verwirrung:

UBL-ElementReguläre RechnungSelf-Billing-RechnungAccountingSupplierPartyDer Absender (Lieferant)Der Empfänger (Lieferant)AccountingCustomerPartyDer Empfänger (Käufer)Der Absender (Käufer)

Die AccountingSupplierParty ist immer der Lieferant, auch wenn der Käufer die Rechnung erstellt. Der Käufer trägt seine eigenen Daten bei AccountingCustomerParty ein.

Idempotency

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.

Fehlerbehandlung

Häufige Fehler beim Self-Billing:

FehlerUrsacheLösungValidierungsfehlerInvoiceTypeCode fehlt oder ist falschPrüfen Sie, dass der InvoiceTypeCode 389 oder 261 istEmpfänger nicht gefundenLieferant nicht für Self-Billing registriertPrüfen Sie über queryRecipientParty; bei BIS Self-Billing muss der Lieferant separat registriert sein409 ConflictDokument mit dieser ID wurde bereits verarbeitetKeine Aktion erforderlich
Webhook-Benachrichtigungen

Nach dem Versand erhalten Sie dieselben Webhook-Events wie bei regulären Rechnungen:

  • InvoiceSent bei erfolgreicher Zustellung
  • InvoiceSentRetry bei einem neuen Versuch (max. 8 Retries)
  • InvoiceSentError wenn die Zustellung endgültig fehlschlägt
Häufig gestellte Fragen
Welchen Endpoint verwende ich für NLCIUS Self-Billing versus BIS Self-Billing 3.0?

Fü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.

Wie sind die Rollen von Lieferant und Käufer im UBL aufgebaut?

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.

Wie verhindere ich doppelte Self-Billing-Übermittlungen und was bei großen Anhängen?

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