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.
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.
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
261zamiast389.
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.
Należy zwrócić uwagę na różnicę w rolach stron przy self-billingu. Jest to częste źródło pomyłek:
AccountingSupplierPartyAccountingCustomerPartyAccountingSupplierParty to zawsze dostawca, nawet gdy nabywca wystawia fakturę. Nabywca wpisuje swoje dane w AccountingCustomerParty.
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.
Częste błędy przy self-billingu:
389 lub 261queryRecipientParty; przy BIS Self-Billing dostawca musi być zarejestrowany oddzielniePo wysłaniu otrzymują Państwo te same zdarzenia webhook co przy zwykłych fakturach:
InvoiceSent przy pomyślnym dostarczeniuInvoiceSentRetry przy nowej próbie (maks. 8 powtórzeń)InvoiceSentError gdy dostarczenie ostatecznie się nie powiedzieDla 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.
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.
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