PEPPOL implementation

[Bastiaan Olij]

Hey Nick,

Around the time I changed jobs I was looking into supporting Peppol and 
may get the chance to dive back into it at some point in the near 
future. It's a classic case of a decent system that is highly 
overengineerd and uses tech that isn't well supported instead of using 
off the shelve standardised APIs.

It's been awhile so I don't remember all the exact terminology they 
introduced but it's best to think of it like a mail server setup but 
instead of sending emails around, you sent invoices around.

They often show a diagram with 4 entities that communicate with 
eachother. At each end there is a peppol client, on "the left" you have 
the peppol client for your client where you send and receive invoices, 
and on "the right" is the peppol client of the entity that you wish to 
communicate with. It is this peppol client that you'll most likely need 
to focus on as you prepare your invoices, and have the peppol client 
handle proper packaging and sending of those invoices as well as reading 
your "inbox" of incoming invoices.

It will come as no surprise that the other 2 entities are the peppol 
servers. One your client is registered at, the other that the other 
party is registered at. Think of these akin to mail servers but without 
the anonymity as every client needs to be properly registered on these 
servers (this is what the whole discovery part is about, so you can be 
sure the other party you're communicating with, is indeed the intended 
recipient of the invoice).

Just like with mail servers you can run your own peppol server, or you 
can use existing servers for a fee.

Now here comes the rub as you may have read on that wiki page. 
Communication between client and server goes over the AS4 protocol.  If 
there ever was a convolute API using tech that very few professionals in 
our business have mastered, hello AS4. The whole ATO here in Australia 
runs on this nonsense and for the longest time the only way to 
communicate with their servers was through some JAVA library that IBM 
eventually made proprietary. Lucky today there are off the shelve 
options as many governments are now using this protocol.

We originally build our own XCOMP to implement this layer for the ATOs 
STP system (payroll) and I still bear the scars :)

There are probably implementations closer to home but I can recommend 
reaching out to these guys: https://layersecurity.com/#/
They are Australian based but have fully implemented the PEPPOL client 
and server. Their PEPPOL client takes the form of a little command line 
tool. You write your invoice to a file on disk, run their command line 
tool, and magically your invoice ends up in the network and at the 
required recipient. Fairly easy to script from Omnis.

Cheers,

Bas

On 27/02/2025 3:08 am, Nick Renders via omnisdev-en wrote:
> Greetings fellow Omnissians,
>
> I was wondering if anyone has any experience with PEPPOL: https://en.wikipedia.org/wiki/PEPPOL
>
> As of 2016, this service will become mandatory in Belgium for creating invoices. I must admit, I am not sure how the whole concept works or where to begin. Is anyone familiar with the process?
>
> Kind regards,
>
> Nick Renders
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com