Why is NL:VAT (9944) not allowed in BR-NL-10?

[ojundt]

We are running into problems with sending invoices through Peppol using SI UBL 2.0 when our clients try to send to Dutch recipients having a NL:VAT (9944) identifier, e.g. ProRail with 9944:nl804170009b01.

Since the recipient is located in NL rule BR-NL-10 applies and requires that the recipient uses either NL:OINO (0190) or NL:KVK (0106). Why is NL:VAT not part of this list?

And if BR-NL-10 cannot be altered to allow NL:VAT, should any Peppol participant located in NL with NL:VAT (9944) identifier be forbidden to list the SI UBL 2.0 document type as supported document type?

[tjeb]

9994 is forbidden in PartyLegalEntity by both the European Norm (EN16931-3-2 page 19, business term BT-47), which limits it to official ISO6523 schemes, and NLCIUS (Gebruikersinstructie voor de basisfactuur 1.0.3, page 58, also BT-47), which, for Dutch organisations, limits it further to only OIN or KvK. The VAT identifier has its own business term (BT-48).

For addressing purposes on the peppol network, there is the cac:Party/cbc:EndpointID element, in which the peppol extension list (of which 9944 is part) are allowed.

[ojundt]

Thanks for the swift response!

The difference between EN16931 and NLCIUS however is that EN16931 allows to leave the PartyLegalEntity/CompanyID element blank if the identifier is not part of the allowed scheme set. BR-NL-10 always requires this field to be present when the recipient is located in NL. This has been changed in f923aa5.

With the current non-blank CompanyId requirement of BR-NL-10 I do not see a possibility to generate a valid SI UBL 2.0 for Dutch recipients using 9944. Do you have an example that shows otherwise?

[tjeb]

The people from TNO made it clear to me that NLCIUS makes the element essentially mandatory (was already implemented, but restated in #27), as well as restrict it to only OIN or KvK; so if you use VAT for addressing, I think you'll need to set both KvK and VAT (and I would then also set EndpointID to the 9944 scheme and value, so that automatic generation of the SBDH can still work). This requirement has other drawbacks (like, say, it excludes potential B2C use-cases from NLCIUS), but from what I have come to understand this is intentional, and if this is an issue, it requires a change request in the NLCIUS, IMHO.

[jdiepenmaat]

To be honest, it all sounds very complicated to me. Identifiers (KvK, btw or OIN) should be used for addressing and preferably not impact the required fields for the content of the message. Can you elaborate on this @WvandenBerg?

[tjeb]

Sorry, I did not mean to imply that, i was trying to say that if you want to derive addressing information from the content of the message, the EndpointID field is the first place to look, not PartyLegalEntity.

[ojundt]

For now we've implemented a solution that requires our users to provide the KvK number as well whenever a NL:VAT address is chosen. However, the question about the intention behind this requirement remains.

[WvandenBerg]

If I remember correctly, the working group that designed the first version of NLCIUS (v1.0.0) wanted to keep the ID type as uniform as possible, hence rule BR-NL-10. The government in particular wanted this, I think.

I will add this as a change request. We'll discuss it in our working group meeting next month.

[tjeb]

Since it's been added as a CR for NLCIUS, I'll close the issue here.

[jdiepenmaat]

As discussed in the Technical NPa meeting (feb 4th 2021) we should reopen this case. @WvandenBerg can you elaborate on the progress that was made in the STPE meeting?

[ri4a]

In the Technical NPa meeting (feb 4th 2021) it was said that there are Dutch organizations that need to receive invoices via Peppol, but do not have KvK number. Could anyone elaborate on that, provide some examples?

[tjeb]

Just want to leave another note here, that came up as well today; if we ever want to expand into B2C we'll need to be able to create invoices where the customer has no legal registration number at all (and no VAT number either, for that matter).