Odeslání self-billing faktury přes API

Implementace self-billingu: varianta NLCIUS a BIS Self-Billing 3.0, kontrola capabilities.

Jako kupující můžete přes PSB API vystavit a odeslat self-billing fakturu jménem Vašeho dodavatele. Tento článek krok za krokem popisuje, jak to udělat pro obě varianty: variantu NLCIUS a Peppol BIS Self-Billing 3.0.

Před začátkem: kontrola capabilities

Vždy nejprve zkontrolujte, zda dodavatel může přijmout požadovaný self-billing formát:

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

V odpovědi vyhledejte podporovaný profil. U NLCIUS je to standardní fakturační profil; u BIS Self-Billing 3.0 specifický self-billing profil.

Varianta 1: NLCIUS (zjednodušená)

Toto je nejjednodušší způsob odeslání self-billing faktury. Používáte stejný CustomizationID a ProfileID jako u běžné NLCIUS faktury, ale změníte 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 = dodavatel (příjemce faktury) -->
  <AccountingSupplierParty>
    <Party>
      <EndpointID schemeID="0106">87654321</EndpointID>
      <PartyName><Name>Leverancier B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingSupplierParty>
  <!-- AccountingCustomerParty = kupující (vystavitel faktury) -->
  <AccountingCustomerParty>
    <Party>
      <EndpointID schemeID="0106">12345678</EndpointID>
      <PartyName><Name>Koper B.V.</Name></PartyName>
      ...
    </Party>
  </AccountingCustomerParty>
  ...
</Invoice>

Dokument odešlete přes 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}

PSB automaticky rozpozná InvoiceTypeCode 389 a nasměruje dokument jako self-billing fakturu dodavateli.

Tip: Pro self-billing dobropis použijte InvoiceTypeCode 261 místo 389.

Varianta 2: BIS Self-Billing 3.0

U tohoto variantu používáte specifický self-billing profil s vlastními identifikátory:

<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>

BIS Self-Billing dokumenty odešlete přes 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}

PSB detekuje self-billing profil na základě CustomizationID a nasměruje dokument dodavateli, pokud je registrován pro profil BIS Self-Billing 3.0.

Rozdíl v rolích

Pozor na rozdíl v rolích stran u self-billingu. To je častý zdroj nejasností:

UBL elementU běžné fakturyU self-billing fakturyAccountingSupplierPartyOdesílatel (dodavatel)Příjemce (dodavatel)AccountingCustomerPartyPříjemce (kupující)Odesílatel (kupující)

AccountingSupplierParty je vždy dodavatel, i když fakturu vystavuje kupující. Kupující uvádí své údaje v AccountingCustomerParty.

Idempotency

Vždy používejte hlavičku X-EConnect-DocumentId k zabránění duplicitnímu odeslání. Pravidla jsou identická s běžnými fakturami: minimálně 6 znaků, nejlépe UUID, nikdy číslo faktury. Více v článku Idempotency.

Zpracování chyb

Časté chyby u self-billingu:

ChybaPříčinaŘešeníValidační chybaInvoiceTypeCode chybí nebo je nesprávnýZkontrolujte, že InvoiceTypeCode je 389 nebo 261Příjemce nenalezenDodavatel není registrován pro self-billingZkontrolujte přes queryRecipientParty; u BIS Self-Billing musí být dodavatel samostatně registrován409 ConflictDokument s tímto ID byl již zpracovánŽádná akce není potřeba
Webhook notifikace

Po odeslání obdržíte stejné webhook eventy jako u běžných faktur:

  • InvoiceSent při úspěšném doručení
  • InvoiceSentRetry při novém pokusu (max 8 retries)
  • InvoiceSentError pokud doručení definitivně selhalo
Často kladené otázky
Jaký endpoint použiji pro NLCIUS self-billing oproti BIS Self-Billing 3.0?

Pro NLCIUS s InvoiceTypeCode 389 nebo 261 a běžnými NLCIUS profily odešlete na POST /api/v1/{partyId}/salesInvoice/send s XML tělem a volitelně X-EConnect-DocumentId. Pro BIS Self-Billing 3.0 s příslušným CustomizationID a ProfileID použijte POST /api/v1/{partyId}/generic/send; PSB rozpozná profil z dokumentu.

Jak jsou v UBL strukturovány role dodavatele a kupujícího?

AccountingSupplierParty je vždy dodavatel (u self-billing strana, která fakturu "přijímá"), a AccountingCustomerParty je kupující, který dokument vytváří a odesílá jménem dodavatele. Toto prohození oproti běžné prodejní faktuře je častá implementační chyba.

Jak zabráním duplicitním self-billing odesláním a co s velkými přílohami?

Používejte stejná pravidla idempotency jako u běžných faktur: odešlete X-EConnect-DocumentId s UUID, ne s číslem faktury. Payloady větší než přibližně 24 MB (včetně overheadu) jsou odmítnuty webovým serverem; zmenšete vložené base64 PDF nebo rozdělte dodávku, přičemž zohledněte přibližně 33% overhead base64.


Chcete dokument nejprve zvalidovat před odesláním? Použijte Validate API pro kontrolu self-billing faktury bez skutečného odeslání.

Vyzkoušejte to v API