Enviar una factura self-billing a través de la API

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.

Previo: verificar capabilities

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.

Variante 1: NLCIUS (simplificado)

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 261 en lugar de 389.

Variante 2: BIS Self-Billing 3.0

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.

Diferencia en los roles

Tenga en cuenta la diferencia en los roles de las partes en self-billing. Esta es una fuente frecuente de confusión:

Elemento UBLFactura estándarFactura self-billingAccountingSupplierPartyEl remitente (proveedor)El destinatario (proveedor)AccountingCustomerPartyEl destinatario (comprador)El remitente (comprador)

El AccountingSupplierParty es siempre el proveedor, incluso cuando el comprador elabora la factura. El comprador rellena sus propios datos en AccountingCustomerParty.

Idempotency

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.

Gestión de errores

Errores comunes en self-billing:

ErrorCausaSoluciónError de validaciónInvoiceTypeCode faltante o incorrectoVerifique que el InvoiceTypeCode sea 389 o 261Destinatario no encontradoProveedor no registrado para self-billingVerifique mediante queryRecipientParty; para BIS Self-Billing, el proveedor debe estar registrado por separado409 ConflictUn documento con este ID ya fue procesadoNo se requiere acción
Notificaciones webhook

Después del envío, recibirá los mismos eventos webhook que para facturas estándar:

  • InvoiceSent en caso de entrega exitosa
  • InvoiceSentRetry en caso de nuevo intento (máx. 8 reintentos)
  • InvoiceSentError si la entrega falla definitivamente
Preguntas frecuentes
¿Qué endpoint utilizo para self-billing NLCIUS versus BIS Self-Billing 3.0?

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

¿Cómo están estructurados los roles de proveedor y comprador en el UBL?

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.

¿Cómo evito envíos self-billing duplicados y qué pasa con adjuntos grandes?

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