Bij reverse billing, c.q. self billing stelt de afnemer een verkoopfactuur op namens de afleverende partij.
De vraag is nu wat dit betekent voor een factuur in UBL en het elektronisch verzenden daarvan via Peppol.

Allereerst zegt de Belastingdienst hierover:
"Als leverancier neemt u deze selfbilling-factuur in uw administratie op als verkoopfactuur. U kunt aan deze factuur zelf een opeenvolgend nummer geven of het door de afnemer gebruikte nummer kiezen.
U bent als leverancier verantwoordelijk voor de betaling van de btw aan ons, ook als dat bedrag te hoog is".
Zie Belastingdienst.

Voorgaande in ogenschouw nemende zou betekenen dat:

• Supplierparty is altijd leverancier (en niet afnemer)
• Customerparty is altijd afnemer (en niet de leverancier)

Anders krijg je ook een kronkel bij de BTW.

Dat de afnemer in dit geval een factuur opmaakt doet niets af aan bovenstaande.

Dat houdt in dat de factuur in UBL wordt samengesteld op dezelfde wijze als dat de leverancier de factuur samenstelt.

Verzenden factuur
Als een dergelijke factuur via email verzonden wordt vanuit de afnemer naar de leverancier moet deze factuur natuurlijk als verkoopfactuur opgenomen worden in het systeem van de leverancier en niet als inkoopfactuur. 

UBL kent de InvoiceTypeCode (Factuurtype code);
Ingeval van Self billing is daarvoor code 389.beschikbaar. 
Op basis van deze code kan dan bepaald wordt dat sprake is van een ontvangen verkoopfactuur.

Als de factuur via een netwerk als Peppol verzonden wordt moet ook de (netwerk)adressering daarop aangepast worden. 
De Nederlandse Peppolautoriteit (NPA) meldt over dit laatste het volgende:

"We concluderen dat de factuur zelf niet omgedraaid dient te worden: dus AccountingSupplierParty blijft de leverancier en AccountingCustomerParty blijft de afnemer. Maar in de Envelop draai je het om (dus in plaats van dat de AccountingSupplierParty/EndpointID in het Sender-veld van de SBDH wordt gezet, zet je hem in de Receiver, en de Customer juist in de Sender). 

Uiteraard vergt dat wel dat je accesspoint/ERP-systeem dat snapt, en vandaar dat de NLCIUS stelt dat je dit van tevoren afgesproken en ingeregeld moet hebben. Dit lijkt ons de correcte manier om het te doen, omdat de uiteindelijke administratie dan gelijk blijft".