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.
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.
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
261invece di389.
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.
Attenzione alla differenza nei ruoli delle parti nel self-billing. Questa è una fonte comune di confusione:
AccountingSupplierPartyAccountingCustomerPartyL'AccountingSupplierParty è sempre il fornitore, anche quando l'acquirente emette la fattura. L'acquirente inserisce i propri dati nell'AccountingCustomerParty.
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.
Errori comuni nel self-billing:
389 o 261queryRecipientParty; per BIS Self-Billing il fornitore deve essere registrato separatamenteDopo l'invio riceve gli stessi eventi webhook delle fatture regolari:
InvoiceSent in caso di consegna riuscitaInvoiceSentRetry in caso di nuovo tentativo (max 8 retry)InvoiceSentError se la consegna fallisce definitivamentePer 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.
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.
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