Inviare una fattura self-billing tramite l'API

Implementare il self-billing: variante NLCIUS e BIS Self-Billing 3.0, verifica delle capabilities.

Come acquirente, tramite la PSB API può emettere e inviare una fattura self-billing per conto del Suo fornitore. Questo articolo descrive passo per passo come procedere per entrambe le varianti: la variante NLCIUS e Peppol BIS Self-Billing 3.0.

Preliminare: verificare le capabilities

Verifichi sempre prima se il fornitore può ricevere il formato self-billing desiderato:

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

Cerchi nella risposta il profilo supportato. Per NLCIUS è il profilo fattura standard; per BIS Self-Billing 3.0 il profilo self-billing specifico.

Variante 1: NLCIUS (semplificato)

Questo è il modo più semplice per inviare una fattura self-billing. Si utilizzano gli stessi CustomizationID e ProfileID di una fattura NLCIUS regolare, ma si modifica l'InvoiceTypeCode in 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>

Invii il documento tramite l'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}

La PSB riconosce automaticamente l'InvoiceTypeCode 389 e instrada il documento come fattura self-billing verso il fornitore.

Suggerimento: per una nota di credito self-billing utilizzi l'InvoiceTypeCode 261 invece di 389.

Variante 2: BIS Self-Billing 3.0

Con questa variante si utilizza il profilo self-billing specifico con propri identificatori:

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

Invii i documenti BIS Self-Billing tramite l'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}

La PSB rileva il profilo self-billing in base al CustomizationID e instrada il documento verso il fornitore, a condizione che sia registrato per il profilo BIS Self-Billing 3.0.

Differenza nei ruoli

Attenzione alla differenza nei ruoli delle parti nel self-billing. Questa è una fonte comune di confusione:

Elemento UBLIn una fattura regolareIn una fattura self-billingAccountingSupplierPartyIl mittente (fornitore)Il destinatario (fornitore)AccountingCustomerPartyIl destinatario (acquirente)Il mittente (acquirente)

L'AccountingSupplierParty è sempre il fornitore, anche quando l'acquirente emette la fattura. L'acquirente inserisce i propri dati nell'AccountingCustomerParty.

Idempotency

Utilizzi sempre l'header X-EConnect-DocumentId per prevenire invii duplicati. Le regole sono identiche a quelle per le fatture regolari: minimo 6 caratteri, preferibilmente un UUID, mai il numero di fattura. Maggiori dettagli nell'articolo Idempotency.

Gestione degli errori

Errori comuni nel self-billing:

ErroreCausaSoluzioneErrore di validazioneInvoiceTypeCode mancante o non correttoVerifichi che l'InvoiceTypeCode sia 389 o 261Destinatario non trovatoFornitore non registrato per il self-billingVerifichi tramite queryRecipientParty; per BIS Self-Billing il fornitore deve essere registrato separatamente409 ConflictUn documento con questo ID è già stato elaboratoNessuna azione necessaria
Notifiche webhook

Dopo l'invio riceve gli stessi eventi webhook delle fatture regolari:

  • InvoiceSent in caso di consegna riuscita
  • InvoiceSentRetry in caso di nuovo tentativo (max 8 retry)
  • InvoiceSentError se la consegna fallisce definitivamente
Domande frequenti
Quale endpoint utilizzo per il self-billing NLCIUS rispetto a BIS Self-Billing 3.0?

Per NLCIUS con InvoiceTypeCode 389 o 261 e i profili NLCIUS consueti, invii a POST /api/v1/{partyId}/salesInvoice/send con body XML e opzionalmente X-EConnect-DocumentId. Per BIS Self-Billing 3.0 con il relativo CustomizationID e ProfileID, utilizzi POST /api/v1/{partyId}/generic/send; la PSB riconosce il profilo dal documento.

Come sono strutturati i ruoli di fornitore e acquirente nel UBL?

AccountingSupplierParty è sempre il fornitore (nel self-billing, la parte che "riceve" la fattura), e AccountingCustomerParty è l'acquirente che crea e invia il documento per conto del fornitore. Questa inversione rispetto a una normale fattura di vendita è un errore di implementazione frequente.

Come evito invii self-billing duplicati e cosa fare con allegati di grandi dimensioni?

Utilizzi le stesse regole di idempotency delle fatture regolari: invii X-EConnect-DocumentId con un UUID, non il numero di fattura. I payload superiori a circa 24 MB (overhead incluso) vengono rifiutati dal web server; riduca i PDF base64 incorporati o suddivida la consegna, tenendo conto di circa il 33% di overhead del base64.


Desidera validare il documento prima di inviarlo? Utilizzi la Validate API per verificare la Sua fattura self-billing senza che venga effettivamente inviata.

Provi nell'API