e-invoice

Hi,

For an e-commerce solution, I understand that an integration with PEPPOL would work as follows:
- The customer could select this payment method during checkout.
- The corresponding payment plugin would then ask for their PEPPOL ID.
- At the end of the checkout process, the plugin would generate a UBL file (using, for example, the library github.com/josemmo/einvoicing )
- The plugin would then connect to the merchant's PEPPOL access point to transmit the UBL file.
- The PEPPOL network would then make the invoice available to the customer via their PEPPOL access point.

The main challenge in all of this is the connection between the plugin and the PEPPOL access point. Different access points offer different APIs to transmit the UBL file. For example, here is the API for the peppol.com access point: api.peppol.com/swagger/index.html

The problem is that if we develop a plugin for peppol.com, but you wish to use another access point, it won't work. Thus, we are in a similar situation as with online payment platforms that act as intermediaries between merchants and customers: a specific plugin must be developed for each PEPPOL access point which we would want to support.

For example, the Qvalia access point has developed a specific plugin for WooCommerce to interface with their PEPPOL autobilling service.

In summary, I currently do not have a clear vision of what we will offer for PEPPOL by 2026. However, if it is something you would like us to develop for you, we could create a payment plugin for the access point of your choice for a several hundred euros. So, I don’t think it will be an issue to have a solution in place by then. It’s more a question of who will pay and how it will be implemented for smaller businesses.

At present, supporting this on an e-commerce site requires paying a subscription with a PEPPOL access point and paying for the development of an integration with that access point if no integration is already available between the e-commerce solution and the access point. This makes it quite burdensome for small businesses. It’s unfortunate that PEPPOL has not also standardized an API for transmitting UBL files to and from access points.

Hi,

Yes, that would be possible. Generating the UBL file and even adding it to the email notification is the easy part.
The problem is the integration with PEPPOL really.

But yes, as you say, you only want to provide the UBL and go through PEPPOL if the customer wants to go with it. That's why I was saying in my previous message that it would require making it as a payment plugin. That way, the customers could choose to go through PEPPOL or not during the checkout.

Hi,

Well, at the end of the checkout, the payment plugin of the selected payment method will either:
- display the payment information (for bank transfer, collect on delivery, check, etc)
- redirect to the payment gateway for the payment
A payment plugin for PEPPOL would send the einvoice to the PEPPOL platform through the API of the platform and then display the payment information, along with a message to the user telling him that the e-invoice has been sent to his PEPPOL account automatically.

Hi,

You mean after the payment ?
In that case, it could be made as a stand alone plugin, and be used with any payment plugin.

Hi,

I think you'll have to send an e-invoice for EU companies with VAT number. Where did you find that this was not the case ?

I'm not clear on whether it will be enough to generate the UBL and send it together with the PDF invoice or if the UBL has to be sent through PEPPOL.
I seems it should be enough but I couldn't find clear information on that.

Ah yes. It will come.

And yes, Scrada.be will be one of the hundreds of PEPPOL access point, each one with their own API :/

I've looked at several APIs for PEPPOL. Many will require providing a UBL file. Some will allow the plugin to provide the details of the invoice with parameters of their API, like Scrada.be does. Some will also ask or offer the possibility to include the PDF of the invoice, like Scrada.be does.
So, for some PEPPOL plugins, an integration with the PDF invoice plugin will be necessary to generate the PDF file to send to the API of the access point.

Hi,

I doubt access points will make plugins.
Having the PDF invoice plugin generate a UBL file will be a good start indeed.

The github can't be used. It's for Node.JS on local networks. We need something in PHP.
As I was saying in my first message, this for example: github.com/josemmo/einvoicing

And yes, it will require extra settings. Not for the email address, but for other things.

Hi,

If you have already purchased the PDF invoice plugin, then you can use the same download link you've received at the time of the purchase to retrieve the latest version from our website.

Hi,

The plugin implements the standard Peppol BIS Billing 3.0 :
docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/
This standard is made for B2B, not B2C, and UBL invoice files without a VAT number for the client are invalid per this standard.
Allowing for UBL invoice files without a VAT number for the client would generate invalid UBL files which would be refused by systems compatible with that standard. I don't think it is a good idea to send the UBL file if it is invalid.
Now, if this standard were to change in a future version to allow B2C, then I suppose the VAT number wont be required, and at that point we'll be able to generate UBL invoice files without a VAT number.
Note also that this is applicable only to the UBL file automatically attached to the emails.
If you edit an order in the backend, you'll get a new "UBL invoice" button and this button will generate you a UBL invoice file even without a VAT number for the client. However, in that case, the UBL invoice will be invalid as per the Peppol BIS Billing 3.0 standard.
So the plugin is capable of doing it, if necessary.

Note also that customers outside the EU can provide a VAT number (or the equivalent in their country, like a company ID or something, in the same field) and the plugin will take it into account and generate a UBL invoice for them.