Implementar self-billing: variante NLCIUS y BIS Self-Billing 3.0, verificar capabilities.
Como comprador, puede a través de la API PSB elaborar y enviar una factura self-billing en nombre de su proveedor. Este artículo describe paso a paso cómo hacerlo para ambas variantes: la variante NLCIUS y Peppol BIS Self-Billing 3.0.
Verifique siempre primero si el proveedor puede recibir el formato self-billing deseado:
GET /api/v1/queryRecipientParty?identifier={schemeID}:{leverancierKvK} HTTP/1.1
Host: psb.econnect.eu
Authorization: Bearer {access_token}
Busque en la respuesta el perfil soportado. Para NLCIUS es el perfil de factura estándar; para BIS Self-Billing 3.0, el perfil self-billing específico.
Esta es la forma más sencilla de enviar una factura self-billing. Utiliza los mismos CustomizationID y ProfileID que para una factura NLCIUS estándar, pero cambia el InvoiceTypeCode a 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>
Envíe el documento a través del 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}
El PSB reconoce automáticamente el InvoiceTypeCode 389 y enruta el documento como factura self-billing hacia el proveedor.
Consejo: para una nota de crédito self-billing, utilice el InvoiceTypeCode
261en lugar de389.
Con esta variante, utiliza el perfil self-billing específico con sus propios identificadores:
<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>
Envíe los documentos BIS Self-Billing a través del 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}
El PSB detecta el perfil self-billing basándose en el CustomizationID y enruta el documento hacia el proveedor, siempre que este esté registrado para el perfil BIS Self-Billing 3.0.
Tenga en cuenta la diferencia en los roles de las partes en self-billing. Esta es una fuente frecuente de confusión:
AccountingSupplierPartyAccountingCustomerPartyEl AccountingSupplierParty es siempre el proveedor, incluso cuando el comprador elabora la factura. El comprador rellena sus propios datos en AccountingCustomerParty.
Utilice siempre el header X-EConnect-DocumentId para evitar envíos duplicados. Las reglas son idénticas a las de facturas estándar: mínimo 6 caracteres, preferiblemente un UUID, nunca el número de factura. Más información en el artículo Idempotency.
Errores comunes en self-billing:
389 o 261queryRecipientParty; para BIS Self-Billing, el proveedor debe estar registrado por separadoDespués del envío, recibirá los mismos eventos webhook que para facturas estándar:
InvoiceSent en caso de entrega exitosaInvoiceSentRetry en caso de nuevo intento (máx. 8 reintentos)InvoiceSentError si la entrega falla definitivamentePara NLCIUS con InvoiceTypeCode 389 o 261 y los perfiles NLCIUS habituales, envíe a POST /api/v1/{partyId}/salesInvoice/send con body XML y opcionalmente X-EConnect-DocumentId. Para BIS Self-Billing 3.0 con el CustomizationID y ProfileID correspondientes, utilice POST /api/v1/{partyId}/generic/send; la PSB reconoce el perfil a partir del documento.
AccountingSupplierParty es siempre el proveedor (en self-billing, la parte que "recibe" la factura), y AccountingCustomerParty es el comprador que crea y envía el documento en nombre del proveedor. Esta inversión respecto a una factura de venta normal es un error de implementación frecuente.
Utilice las mismas reglas de idempotency que para facturas regulares: envíe X-EConnect-DocumentId con un UUID, no el número de factura. Los payloads superiores a aproximadamente 24 MB (incluyendo overhead) son rechazados por el servidor web; reduzca los PDFs base64 incrustados o divida la entrega, teniendo en cuenta aproximadamente un 33% de overhead por base64.
¿Desea primero validar el documento antes de enviarlo? Utilice la Validate API para verificar su factura self-billing sin enviarla realmente.
Probar en la API