The french B2B eInvoicing & VAT eReporting mandate creates a status of PDP (Platform Partner of Dematerialization). A PDP is a certified service provider able to carry out both eInvoicing on behalf of its customer and eReporting on behalf of the tax authority. To become a PDP, service provider will have to go through a cumbersome journey to demonstrate its capability and its conformance to security requirements. For awarded providers, the PDP status will give an unprecedented trustworthy position on the market. This status may lead also to increase dramatically their responsability. In carrying out eReporting a PDP will become more deeply rooted to the business of its customer . This situation of dependency may expose the service provider to unreasonnable consequences with a subsequent question : who actually owns the process and who bears the responsibility?
In the B2B model, the PDP takes a central role in VAT eReporting but also to garantee eInvoicing interoperability to reach the final recipient. Pursuant to that mission, the position as intermediary contractually binds the service provider to ensure the end to end completion of the transaction on behalf of a customer who is unlikely to perform it himself. In that sense, the increased level of responsability that could entail a virtual transfer of ownership of certain process to the service provider raises question. For example, if a transaction involves several parties (factoring, subcontracting, payer, payee, invoicee etc.) the service provider cannot be held liable for partial completion of the service due to a non responsive third party. Another risk could araise from the shared responsibility between the two PDP involved in the transaction (sending PDP and the counterpart PDP of the recipient). The sending PDP knows only its customer. Accordingly, it is contractually bound to perform specific tasks while the receiving party might not be. The second player may also have a restricted responsibility on the process occuring downstream. In that case, what could happen if the service rendered is a complex use case with a convoluted choreography of transactions involving third parties ? In that context, it could be useful to state on the actual scope of responsibility in respect of their assignment as PDP or envisage an overarching convention like an interoperability agreement superseeding individual responsabilities.
It could be also useful to separate more clearly the role of PDP in establishing interoperability of transactions with the specific billing frameworks that lead to these transactions. OpenPEPPOL can provide the interoperability layer necessary between PDP using its automatic discovery capability (SMP/SML). PEPPOL has been designed to ensure routing between two access points but not to manage a complex business process. For example, PEPPOL will not support directly self invoicing (when a customer assumes responsibility for issuing their supplier’s VAT invoice). There is no billing profile for that. But PEPPOL will support the transaction resulting of this process, completed outside of the loop of transactions. Asking PEPPOL to perform tasks for which it has not been designed would certainly create a messy situation.
We could be surprised to see how some organization unable to properly manage their process internally, would grab the opportunity of this reform to transfer the burden and the risk at the same time to their service provider. In that process, PDP could face a dilemna, support their customer sometimes beyond the scope of mission while being a gatekeeper of the tax authority in VAT eReporting.