Wysyłanie faktury self-billing przez API

Implementacja self-billing: wariant NLCIUS i BIS Self-Billing 3.0, sprawdzanie capabilities.

Jako nabywca mogą Państwo przez PSB API wystawić i wysłać fakturę self-billing w imieniu dostawcy. Ten artykuł opisuje krok po kroku, jak to zrobić dla obu wariantów: wariantu NLCIUS i Peppol BIS Self-Billing 3.0.

Wstępnie: sprawdzenie capabilities

Zawsze należy najpierw sprawdzić, czy dostawca może odebrać żądany format self-billing:

GET /api/v1/queryRecipientParty?identifier={schemeID}:{leverancierKvK} HTTP/1.1
Host: psb.econnect.eu
Authorization: Bearer {access_token}

W odpowiedzi należy wyszukać obsługiwany profil. Dla NLCIUS jest to standardowy profil faktur; dla BIS Self-Billing 3.0 specyficzny profil self-billing.

Wariant 1: NLCIUS (uproszczony)

To najprostszy sposób wysłania faktury self-billing. Używa się tych samych CustomizationID i ProfileID jak przy zwykłej fakturze NLCIUS, ale zmienia się InvoiceTypeCode na 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 = de leverancier (ontvanger van de factuur) -->
  <AccountingSupplierParty>
    <Party>
      <EndpointID schemeID="0106">87654321</EndpointID>
      <PartyName><Name>Leverancier B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingSupplierParty>
  <!-- AccountingCustomerParty = de koper (opsteller van de factuur) -->
  <AccountingCustomerParty>
    <Party>
      <EndpointID schemeID="0106">12345678</EndpointID>
      <PartyName><Name>Koper B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingCustomerParty>
  ...
</Invoice>

Dokument wysyła się przez endpoint SalesInvoice:

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}

PSB automatycznie rozpoznaje InvoiceTypeCode 389 i kieruje dokument jako fakturę self-billing do dostawcy.

Wskazówka: dla noty kredytowej self-billing należy użyć InvoiceTypeCode 261 zamiast 389.

Wariant 2: BIS Self-Billing 3.0

W tym wariancie używa się specyficznego profilu self-billing z własnymi identyfikatorami:

<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>Leverancier B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingSupplierParty>
  <AccountingCustomerParty>
    <Party>
      <EndpointID schemeID="0106">12345678</EndpointID>
      <PartyName><Name>Koper B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingCustomerParty>
  ...
</Invoice>

Dokumenty BIS Self-Billing wysyła się przez endpoint Generic:

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}

PSB wykrywa profil self-billing na podstawie CustomizationID i kieruje dokument do dostawcy, pod warunkiem że jest on zarejestrowany dla profilu BIS Self-Billing 3.0.

Różnica w rolach

Należy zwrócić uwagę na różnicę w rolach stron przy self-billingu. Jest to częste źródło pomyłek:

Element UBLPrzy zwykłej fakturzePrzy fakturze self-billingAccountingSupplierPartyNadawca (dostawca)Odbiorca (dostawca)AccountingCustomerPartyOdbiorca (nabywca)Nadawca (nabywca)

AccountingSupplierParty to zawsze dostawca, nawet gdy nabywca wystawia fakturę. Nabywca wpisuje swoje dane w AccountingCustomerParty.

Idempotency

Należy zawsze używać headera X-EConnect-DocumentId, aby zapobiec podwójnemu wysyłaniu. Reguły są identyczne jak dla zwykłych faktur: minimum 6 znaków, najlepiej UUID, nigdy numer faktury. Więcej w artykule Idempotency.

Obsługa błędów

Częste błędy przy self-billingu:

BłądPrzyczynaRozwiązanieBłąd walidacjiInvoiceTypeCode brakuje lub jest nieprawidłowyNależy sprawdzić, czy InvoiceTypeCode to 389 lub 261Odbiorca nie znalezionyDostawca nie jest zarejestrowany dla self-billingSprawdzenie za pomocą queryRecipientParty; przy BIS Self-Billing dostawca musi być zarejestrowany oddzielnie409 ConflictDokument o tym ID został już przetworzonyNie jest wymagana żadna akcja
Powiadomienia webhook

Po wysłaniu otrzymują Państwo te same zdarzenia webhook co przy zwykłych fakturach:

  • InvoiceSent przy pomyślnym dostarczeniu
  • InvoiceSentRetry przy nowej próbie (maks. 8 powtórzeń)
  • InvoiceSentError gdy dostarczenie ostatecznie się nie powiedzie
Często zadawane pytania
Jakiego endpointu użyć dla self-billing NLCIUS a jakiego dla BIS Self-Billing 3.0?

Dla NLCIUS z InvoiceTypeCode 389 lub 261 i standardowymi profilami NLCIUS, należy wysyłać do POST /api/v1/{partyId}/salesInvoice/send z body XML i opcjonalnie X-EConnect-DocumentId. Dla BIS Self-Billing 3.0 z odpowiednim CustomizationID i ProfileID należy użyć POST /api/v1/{partyId}/generic/send; PSB rozpoznaje profil z dokumentu.

Jak wyglądają role dostawcy i nabywcy w UBL?

AccountingSupplierParty to zawsze dostawca (w self-billing strona, która "otrzymuje" fakturę), a AccountingCustomerParty to nabywca, który tworzy i wysyła dokument w imieniu dostawcy. To odwrócenie w porównaniu ze standardową fakturą sprzedażową jest częstym błędem implementacyjnym.

Jak zapobiec podwójnym wysyłkom self-billing i co z dużymi załącznikami?

Należy stosować te same zasady idempotency co dla zwykłych faktur: wysyłać X-EConnect-DocumentId z UUID, nie z numerem faktury. Payloady przekraczające ok. 24 MB (łącznie z narzutem) są odrzucane przez serwer WWW; należy zmniejszyć osadzone PDFy base64 lub podzielić dostawę, uwzględniając ok. 33% narzutu base64.


Chcą Państwo najpierw zwalidować dokument przed wysłaniem? Należy użyć Validate API, aby sprawdzić fakturę self-billing bez jej faktycznego wysyłania.

Wypróbuj w API