Electronic invoices OVH SAS: schemeID 0002 on BT-34 causes a "B2BInt" rejection at SuperPDP

Customer area and account settings
1

Hello,

I am the developer of DolifacturX, an electronic invoicing module for Dolibarr, and I am reporting a technical issue affecting invoices issued by OVH SAS (SIREN 424761419).

Constat: on the OVH invoices received, the seller's electronic address field (BT-34, cac:AccountingSupplierParty/cac:Party/cbc:EndpointID) carries schemeID="0002" (raw SIREN, ISO 6523):

<cbc:EndpointID schemeID="0002">424761419</cbc:EndpointID>

whereas the expected scheme for a French routing address on the interoperable e‑invoicing network is 0225 (SIREN in GEBA/Peppol France format).

Conséquence: the accredited recipient platform (SuperPDP, in the documented case below) classifies the invoice itself as "B2BInt" (international transaction) on this basis, and then rejects any life‑cycle status transmission other than payment receipt (acceptance, rejection, payment processing) with an error such as "B2BInt invoices only support payment received event (le 212)". This blocks the normal invoice processing workflow on the buyer side.

Ce n'est pas un problème isolé à un module: the same symptom has been reported independently on several market solutions: DolifacturX, LemonFacturX/LemonSuperPDP, and the official/community e‑invoicing module of Dolibarr. See the discussion thread on the Dolibarr forum: https://www.dolibarr.fr/forum/t/super-pdp-les-factures-b2bint-ne-supportent-que-le-statut-fr-212/51860

Note that the business note #BAR#B2B present in the body of your invoices is correct, so the problem does not come from there, but from the schemeID of the EndpointID.

Notre question: is this choice of schemeID 0002 rather than 0225 an error to be corrected on OVH's side, or a deliberate usage? If it is a legitimate usage, could you clarify the reason, knowing that SuperPDP itself seems not to accept it in practice (B2BInt rejection on status transmission)?

Thank you in advance for your reply.

2

Hello @Dzprod,

I have forwarded the information to the relevant department which will review your request.

You will receive a response as soon as possible regarding this matter.

We apologize for any inconvenience caused.

^FabL

3

Hello @Dzprod,

Here is the feedback from the team in charge of electronic invoicing:

Hello,

Thank you for this report, precise and useful.

What we confirm: we have verified that on invoices issued by OVH SAS, the field

BT-34 (cac:AccountingSupplierParty/cac:Party/cbc:EndpointID) contains the SIREN 424761419 with

schemeID="0002". Your observation is correct.

On the field itself: code 0002 (SIRENE, ISO 6523) is part of the EAS code list approved for the seller’s electronic address. The format 0225 is required for BT-34 in the case of self‑billing, which is not the case for these invoices. At this stage of our analysis,

the issuance therefore complies with the EN 16931 validation rules and the CTC‑FR applied to the document.

Regarding the B2BInt qualification: these invoices fall under domestic B2B processing, and this

qualification is carried by the document itself: a note (BG‑1) with a subject code

BT‑21 = BAR and a content BT‑22 = B2B. It is this note that declares the expected processing, and not the identification scheme of the seller’s address. If the invoice you examined does not contain this note, please let us know; the information would be useful to us.

What is actionable from your side right now: the return of lifecycle statuses is performed platform‑to‑platform, not directly to the issuer. The rule in force on the network, confirmed by our issuing platform, provides that when no usable electronic issuance address is present in the invoice, the lifecycle statuses are sent back to the issuing platform identified in the transport envelope: for a PEPPOL delivery, the senderId of the SBDH envelope, which is a PEPPOL address and not the document’s electronic address. Acceptance, rejection and payment‑in‑process statuses can therefore be transmitted via this route without waiting for any change on our side. Your receiving platform is able to confirm this point.

Further follow‑up: the issue you raise – the return address to be included in the document – is currently under technical review with our issuing platform. At this stage we cannot commit to any change of the field nor to a timeline. We will get back to you if a modification is decided.

To help us move forward, could you provide: the invoice number(s) concerned, the name of the receiving platform, the date of the attempt and, if possible, the full error message?

Best regards,
4

Very well, thank you for this quick and detailed response.
I will get in touch with PA SuperPDP and ask them for the exact reason for their rejection of the lifecycle transmission on your invoices and why they mark them as B2BINT (even though your BAR code is indeed B2B, moreover).

5

Hello,

This is SUPER PDP.

Quick version: bug on our side, we just fixed it.

Long version: it's very unusual to send an invoice with schemeID="0002" and not "0225" in BT-34, which explains why some Approved Platforms (and we’re not the only ones) had a problem with that. But it’s not prohibited, so we fixed it on our end.

We just had a discussion about this in an AFNOR group, and it confirmed to me that this is not in the spirit of the standard, and that OVH should be encouraged to set its BT-34 to 0225.

Martin
SUPER PDP

https://www.superpdp.tech