Wat is Peppol BIS Self-Billing 3.0 (UBL 2.1)?

Dit helpartikel legt Peppol BIS Self-Billing 3.0 uit op een gestructureerde en eenvoudige manier, met focus op wat een eindgebruiker (verzender of ontvanger), softwareleverancier en Peppol serviceprovider nodig hebben om het volledige self-billing e-factuurproces te ondersteunen.

Let op: land specifieke btw- en self-billing voorwaarden kunnen afwijken. In het helpartikel beschrijven we vooral het Peppol/BIS-proces en de technische inrichting. Voor nationale eisen (acceptatieprocedures, archivering, extra velden) kan aanvullend land onderzoek nodig zijn.

1. Wat is self-billing?

Self-billing betekent dat de klant (in de e-factuur: buyer/customer) de factuur opstelt namens de leverancier (in de e-factuur: seller/supplier).

• Bij een reguliere factuur maakt de leverancier de factuur en stuurt die naar de klant.
• Bij self-billing maakt de klant de factuur voor/namens de leverancier.
• De Nederlandse belastingdienst heeft regels voor selfbilling. In Peppol wordt dit gefaciliteerd met een apart profiel: Peppol BIS Self-Billing 3.0.

2. Belangrijkste verschillen tussen Billing en Self-Billing

2.1 Richting van verzending in Peppol

De partij (de klant) die de e-factuur moet betalen blijft de crediteur en de partij (de leverancier) die een vordering heeft blijft de debiteur.

Een van de grootste valkuilen in software implementaties: systemen die altijd aannemen dat de AccountingSupplierParty de Sender is. 

2.2 Ander profiel en andere identificaties in de XML

Self-billing gebruikt andere waarden in de e-factuur (de XML) bij de velden cbc:CustomizationID en cbc:ProfileID. Daarmee kan een ontvanger (en de Peppol bericht validatie) herkennen dat het om Self-Billing 3.0 gaat, en niet om Billing 3.0.

Als deze elementen verkeerd zijn ingevuld, kan het document verkeerd gerouteerd worden (bijvoorbeeld als normale factuur) of falen in validatie bij de ontvanger. De verzendende en de ontvangende administratieve software zal de e-factuur juist registreren en boeken als bovenstaande gegevens juist zijn opgenomen. Als de administratieve software niet in staat is om deze gegevens zelf te verwerken, dan zorgt de Peppol serviceprovider ervoor dat de gegevens vertaald worden. De administratieve software en de Peppol serviceprovider zorgen dan onderling voor integratie tussen de software en het Access Point.

2.3 Correcties en credit nota’s

Self-billing scenario's ondersteunen correcties op twee manieren: via een self-billed credit note of via een negatieve invoice (regel) met negatieve totalen (middels berekening negatieve hoeveelheid x positieve prijs). Een ontvangende partij moet beide vormen kunnen verwerken en de boekhoudlogica hierop afstemmen.

Het verdient de aanbeveling bij een creditnota de gehele debet te crediteren en indien van toepassing een nieuwe correcte self-billing factuur te maken.

2.4 Andere documenttypen voor SMP/publicatie

Self-billing heeft eigen documenttype identifiers (document type IDs) voor publicatie in de Peppol SMP (Service Metadata Publisher). Wanneer een partij dus self-billing facuren moet kunnen ontvangen en verwerken moeten de bijbehorende types zijn geregistreerd bij die partij. Veelal zal dit naast de reguliere types zijn. Controleer deze link voor alle document types:

https://docs.peppol.eu/edelivery/codelists/

2.5 Referenties

Self-billing vraagt in de praktijk om sterke herleidbaarheid naar contracten/raamovereenkomsten, orders (PO), buyer references en ontvangst-/leveringsdocumenten (zoals leverbonnen, meetstaten of timecards). De verzend software moet deze referenties waar relevant kunnen verwerken en meesturen in de XML.

3. Rollen: wie is wie?

Bij self-billing zijn er drie verschillende perspectieven op de voorkomende rollen. Dit kan wat verwarrend zijn. De onderstaande tabel geeft een compleet overzicht:

Let op: de afzender (sender) is dus de klant, maar in de XML-inhoud blijft de klant de AccountingCustomerParty. Dit geeft de eerder genoemde verwarring in implementaties.

4. Het businessproces

Het self-billing proces verloopt in vijf stappen:

┌─────────────────────┐

│ 1. Self-billing │Buyer en seller maken afspraken over nummering, referenties, acceptatie en termijnen│afspraak │     Toets of de administratieve software het kan verwerken al dan niet in samenspraak met de serviceprovider

└──────────┬──────────┘ 

                          │                                 

                          ▼       

┌─────────────────────┐

│ 2. Levering/                            │  Buyer ontvangt/accepteert geleverde goederen/diensten

│    afname                                 │ 

└──────────┬──────────┘

                           │

                          ▼

┌─────────────────────┐

│ 3. Opstellen                           │ Buyer stelt factuur op in self-billing profiel

│    self-billed                             │ met correcte typecodes en referenties (zie 5.)

│    invoice                                   │

└──────────┬──────────┘

                           │

                          ▼

┌─────────────────────┐

│ 4. Verzenden via                  │  Buyer → Access Point → Supplier

│    Peppol                                   │  (richting is omgekeerd t.o.v. reguliere factuur)

└──────────┬──────────┘

                           │

                          ▼

┌─────────────────────┐

│ 5. Verwerken door            │ Supplier accepteert (of i.v.t. weigert of disputed)

│    supplier                               │ Correcties via self-billing credit note of self-billing invoice

└─────────────────────┘

5. Aandachtspunten voor softwareleverancier en serviceprovider

5.1 SMP/publicatie en capability management

Omdat self-billing eigen document type IDs heeft, moet bij de ontvanger (de supplier) in de SMP worden gepubliceerd dat kan worden ontvangen:

• Self-Billing Invoice
• Self-Billing CreditNote

Zonder deze publicatie kan een sender niet versturen.

5.2 Routing: ontvanger is de supplier

Bij self-billing is de supplier de Peppol-ontvanger. Dat betekent:

• de sender zoekt het endpoint van de supplier op,
• het Access Point levert af bij de supplier.

Als het systeem "ontvanger = customer" hardcoded heeft, moet dit worden aangepast.

5.3 Validatie en rulesets

Self-billing gebruikt een eigen profiel. Zorg dat de validatieketen het juiste profiel kiest op basis van:

• CustomizationID
• ProfileID
• Schema (Invoice / CreditNote)

Aanbevolen technisch ontwerp:

• Een validator die profile-based kan valideren (Billing vs Self-Billing).
• Logs met duidelijke foutclassificatie (schemafout, business rule, ontbrekende verplichte velden).

5.4 Status- en audit trail in de in gebruik zijnde  applicatie

Self-billing is functioneel gevoelig: "wie heeft, wat, wanneer geaccepteerd?"

Modelleer minimaal:

• Documentstatus: concept → verzonden → ontvangen → verwerkt → geaccepteerd / betwist / afgewezen
• Relaties: invoice ↔ credit note ↔ vervangende invoice
• Bewijslast: referenties, contract-id, order-id, en interne acceptatiestap

5.5 Correctieflow (dispute/acceptatie)

Peppol Self-Billing beschrijft het proces (approve/reject/dispute), maar schrijft niet altijd een uniforme "response message" voor, in elk ecosysteem. Daarom is het belangrijk dat de oplossing:

• ondersteunt dat acceptatie "stilzwijgend" kan zijn (bijvoorbeeld alleen boeking),
• ondersteunt dat acceptatie expliciet kan zijn (bijvoorbeeld via portal/notification),
• duidelijke afspraken faciliteert (SLA/contract).

Als al een Invoice Response of statuskoppeling in gebruik is in andere processen, is het verstandig om te onderzoeken hoe dit met self-billing in de klantketen past.

5.6 Autorisatie en veiligheid

Omdat de buyer namens de supplier factureert, zijn drie aspecten kritiek: 

• duidelijke autorisatie (wie mag namens wie facturen maken),
• nummering volgens afgesproken series (verschilt per klant/land/boekhoudsysteem),
• en integriteit via logging, audit trail en waar nodig tamper-evident opslag.

6. Ontwerpaanpak: wat moet de oplossing minimaal kunnen?

7. Praktische valkuilen

8. Begrippenlijst