Peppol & e-facturatie

Selfbilling: wie is de verkoper?

Gepubliceerd: 2026-10-21 · Bronnen gecontroleerd: 2026-10-21

Bij selfbilling maakt de afnemer de factuur op voor de levering van de verkoper. De opsteller wordt daardoor niet ineens de verkoper. Controleer daarom eerst de afspraak en partijrollen, en daarna het ondersteunde selfbilling-formaat. Alleen een andere titel boven dezelfde gewone factuurexport zetten is geen controle van het proces.

Kort antwoord

Leg voor één concept vast wie levert, wie afneemt en wie het document opstelt. Vergelijk die rollen met de partijgegevens in de export. Vraag je softwareleverancier specifiek naar Peppol BIS Self-Billing; ondersteuning voor het versturen van gewone facturen bevestigt op zichzelf niet dat deze andere richting wordt ondersteund.

Onze uitleg gebruikt de gepubliceerde OpenPeppol-documentatie voor BIS Self-Billing 3.0. Die toont bij controle de May 2026 Release. De release notes noemen versie 3.0.2. Het eigen proefblad hieronder vergelijkt vier punten, zonder een echte factuur te verzenden of een volledige XML-validatie uit te voeren.

Opsteller en verkoper zijn verschillende rollen

In het OpenPeppol-proces voor selfbilling stelt de klant het document op in naam van de leverancier en stuurt het naar die leverancier. De klant verwerkt het als inkoop; de leverancier ontvangt het voor zijn verkoopadministratie. De richting van de uitwisseling verandert dus, terwijl de onderliggende levering haar leverancier en afnemer houdt.

Maak zelf een klein rollenblad voordat je een pakketdemonstratie volgt. Zet de leverancier boven het vak “verkoper” en de klant boven “afnemer”. Zet “opsteller/verzender” op een afzonderlijke regel. Controleer vervolgens of de demonstrateur over de verzendende partij praat of over de verkoper in het document. Twee keer dezelfde naam horen is zonder die rol onvoldoende om de koppeling te beoordelen.

Houd een eventuele andere betalingsontvanger daarnaast apart. Onze uitleg over verkoper, begunstigde en rekeningnaam gaat over hun afzonderlijke betekenis. Gebruik de opsteller van een selfbilling-factuur evenmin als vervanging voor een van die rollen.

Controleer eerst de afspraak en beoordeling

De Belastingdienst over selfbilling verlangt een voorafgaande afspraak en de vermelding factuur uitgereikt door afnemer. De leverancier blijft verantwoordelijk voor de juistheid en de btw-betaling, ook bij een te hoog btw-bedrag. De factuur moet aan de wettelijke regels voldoen en komt bij de leverancier in de verkoopadministratie.

Volgens dezelfde uitleg moet de leverancier een niet-akkoord tijdig melden; de factuur is dan ongeldig. De leverancier moet zelf factureren, tenzij partijen het eens worden over een verbeterde factuur. De factuur staat op naam van de dienstverrichter, met de afnemer als geadresseerde. Een creditfactuur op eigen naam van de afnemer is daarvoor niet juist.

Onze praktische voorbereiding is om bij de afspraak ook de contactpersoon, beoordelingsstap en opvolging van een verschil te noteren. Leg vast wie een ontvangen concept onderzoekt en waar een reactie wordt bewaard. We leiden uit de officiële term “tijdig” geen algemeen aantal dagen af. Een gevonden softwarefunctie is geen beoordeling van een echte afspraak of specifieke factuur.

Vraag naar specificatie, proces en documenttype

De afzonderlijke syntaxpagina's beschrijven CustomizationID, BT-24 als specificatie-identificatie en ProfileID, BT-23 als procesidentificatie. Beide hebben cardinaliteit 1..1. De daar getoonde waarden voor dit selfbilling-profiel zijn:

Specificatie: urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0

Proces: urn:fdc:peppol.eu:2017:poacc:selfbilling:01:1.0

Daarnaast benoemt InvoiceTypeCode, BT-3 het functionele documenttype. Ook dat element heeft cardinaliteit 1..1. De gekoppelde selfbilling-codelijst noemt 389 voor een self-billed invoice en daarnaast 527 voor een self billed debit note. Ons voorbeeld kiest alleen de eerste situatie.

Laat voor je eigen uitwisseling aantonen hoe formaat, proces en documenttype worden gekozen. Vervang niet handmatig een identifier in een los bestand om van een gewone export een selfbilling-export te maken. Vraag welk bronveld het pakket gebruikt en hoe de andere partij deze documentsoort ontvangt. Houd dit naast de algemene controle van formaat en leesbare weergave.

Lees de verkoper op zijn eigen plaats

In de selfbilling-syntax beschrijft AccountingSupplierParty, BG-4 de verkoper. De groep heeft cardinaliteit 1..1. AccountingCustomerParty, BG-7 beschrijft de koper en heeft eveneens cardinaliteit 1..1. Dat de klant het bestand opstelt, wisselt de betekenis van deze twee groepen niet om.

Laat de inhoudsweergave daarom de bovenliggende groep tonen. Een naam zoeken zonder de plek in de structuur te bekijken, is onvoldoende: de klantnaam mag als afnemer terugkomen zonder de verkoper te worden. Bewaar op het rollenblad de bedoelde partij naast de aangetroffen waarde en de gebruikte conceptversie.

Eigen proef: één verkeerd ingevulde verkoper

We verzinnen dossier SB2110. Atelier L is de leverancier van de dienst en Bureau K is de afnemer. Voor deze papieren oefening nemen we aan dat vooraf is afgesproken dat Bureau K de factuur opstelt. We hebben geen overeenkomst onderzocht. Het concept heet C1 en gebruikt voor onze fictieve self-billed invoice typecode 389.

Onderdeel	Verwachting en concept C1
Verkoper	Verwacht: Atelier L BG-4 in C1: Bureau K
Afnemer	Verwacht: Bureau K BG-7 in C1: Bureau K
Type	Verwacht: self-billed invoice BT-3 in C1: 389
Vermelding	Verwacht en leesbaar in C1: factuur uitgereikt door afnemer

Van onze vier afgebakende punten sluiten afnemer, type en leesbare vermelding aan. Er blijft 4 − 3 = 1 afwijking: Bureau K is ook als verkoper ingevuld. De juiste afnemer en typecode maken dat verkeerde verkopersgegeven niet goed. De leesbare vermelding in deze proef bevestigt evenmin op welke plaats een echt pakket haar gestructureerd verwerkt.

We vergelijken hier geen bedragen, btw-tarieven, adressen of alle andere factuurgegevens. “Drie punten sluiten aan” betekent dus niet dat de overige factuur al is goedgekeurd. De vierpuntscontrole is een eigen afbakening voor deze demonstratie.

Herstel het brongegeven en controleer opnieuw

Laat in onze fictieve situatie uitzoeken waarom het pakket Bureau K in de verkopersgroep heeft geplaatst. Vraag welk bedrijfs- of relatiegegeven die groep voedt. Maak daarna volgens de pakketwerkwijze een nieuw concept C2 en lees de partijgroepen opnieuw. Verander niet ook de afnemer naar Atelier L om alleen twee verschillende namen te krijgen.

Als C2 Atelier L als verkoper toont en de drie andere punten behouden blijven, sluiten alle vier aan bij dit beperkte oefenblad. Bewaar C1 als onderzochte versie en C2 als hercontrole, met een korte beschrijving van de wijziging. Gebruik een echte verzending of boeking niet als proef om te ontdekken welke partij het pakket bedoelt.

De BIS beschrijft afzonderlijke validatielagen voor syntax en factuurregels. Vraag dus ook naar een validatierapport voor het gekozen selfbilling-profiel. Een herstelde partijnaam is geen volledige validatie, akkoord van de leverancier of bevestiging van betaling.

Bewaar afspraak, versie en uitkomst samen

Maak het dossier leesbaar voor degene die later een vraag moet opvolgen: welke afspraak was het uitgangspunt, wie was leverancier, wie stelde het document op en welke versie is onderzocht? Bewaar de gestructureerde gegevens bij de bijbehorende leesbare weergave. Leg een reactie op een afwijking bij die versie vast.

Noteer de uitkomsten afzonderlijk: rollen vergeleken, verschil hersteld, technische validatie ontvangen en inhoudelijk beoordeeld. Een groen vinkje bij verzending of één gevonden typecode vertelt niet hoe de overige stappen zijn verlopen. Deze werkwijze is bedoeld om vragen terug te kunnen vinden; er is geen echte klantadministratie aangepast.

Bronnen en verder lezen

Tien primaire HTML-bronnen gecontroleerd op 21 oktober 2026. De geselecteerde gepubliceerde Self-Billing-documentatie toont May 2026 Release, versie 3.0.2. Het dossier SB2110, de partijlabels, concepten en vierpuntsvergelijking zijn onze eigen fictieve uitwerking. Geen echte overeenkomst beoordeeld, factuur verzonden, betaling uitgevoerd of volledig XML-bestand gevalideerd.