To deliver an e-invoice AutoInvoice uses the electronic invoicing address and the operator code of the recipient. If only recipient’s e-invoice address or organization number is given AutoInvoice does a lookup to find the rest of the information.
The recipient information can be given as
Embedded in the XML
Operator code and e-invoicing address can be delivered within fields in the XML.
Please see from the XML format specifications where this information should be embedded in the XML format you are using.
For example, in Finvoice format the e-invoicing address and operator code are provided in SOAP envelope or in MessageTransmissionDetails -element. If both are given the MessageTransmissionDetails -element overrides the information provided in the SOAP. It is recommended to use MessageTransmissionDetails -element.
If routing information is provided in both metadata and XML, the information in the metadata overrides the information provided in the XML.
Please note that specifying the operator code affects routing, so it should only be given when the sender knows this information. We use given operator information only in case it is a valid operator, no matter how the operator information is given (metadata or embed in the XML).
The default order to route an invoice is
E-invoice is tried first, and email and print are used as fallbacks.
If only recipient’s e-invoice address or organization number are given, and no valid electronic route can be found the fallback routes are automatically tried.
The fallback routes are NOT used if invoice has been sent to specific electronic route. The specific route means that in sending both electronic invoice address (EIA) and operator information are given (e.g. 0192:123456789, PEPPOL). In this case invoice is sent directly to specific route and no other routes are searched or tried. The system considers that the invoice is meant to be send as an e-invoice to that specific address and the sender would like to know if that e-invoice route fails.
Disabling routes specifically is also possible in the sending API call.
If you want to find out if a company can receive electronic invoices through AutoInvoice or through external operators before the send, you can use API method:
The searches can be done using indentifiers such as company name, company organization number or business ID, VAT code or e-invoice address (e.g. EDI, OVT, EAN, GLN).
Customers / companies use Peppol Access Points to send and receive in the Peppol network. To receive a document type company needs to register a profile to receive it.
To do lookups and see active registrations Peppol uses SML/SMP (Service Metadata Locator / Service Metadata Publisher) structure, where SML is the master data that points to correct SMP that contains details of the participant company. SML can be considered as an address book that points to the right SMP which has company’s receiving capabilities registered.
There are multiple different Peppol registries, like Peppol directory and Elma but all of them do the lookup with the SML/SMP infrastructure, what you could call the “real look-up”. It is always done with a specific type+ID combination, e.g. for Norwegian company 0192:123456789. See technical details how this work below.
This real Peppol lookup is the only thing that matters in the end. If there are no profiles registered for an identifier using this method then it means that identifier is not registered in the Peppol network to receive documents. If the Peppol lookup can’t find the recipient it means it is not registered with that ID at least.
Read more about Peppol from here.
The Access Points use an SMP (Service metadata publisher) provider to register their customers to the Peppol network. The SMP provider has an integration to the SML (Service metadata locator). The SML uses the global internet DNS system for mapping participants to SMPs.
Read more about these from peppol.org
MD5 hash is generated from the identifier which is combined with the common URL, and that is it.
For example identifier 0192:933646920 which is Visma Software AS.
With MacOS or (any Linux, maybe) you can get the MD5 hash on command line like this:
md5 -s 0192:933646920
MD5 ("0192:933646920") = 9981849f1e548b13ef84dab8e29948b1
Now combine 9981849f1e548b13ef84dab8e29948b1 with the URL iso6523-actorid-upis.edelivery.tech.ec.europa.eu and add a B- to the beginning and the cleartext identifier to the end, like so: http://B-9981849f1e548b13ef84dab8e29948b1.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis::0192:933646920
This is now the lookup URL.
The SML has made it so that this hostname in the global internet DNS system points to the SMP that registered it and the reply you get when you go to this URL (go ahead, try it with your browser!) is coming from the SMP. The reply lists all the URLs for specific document types this participant is registered to receive. Then looking at those URLs you can see more details. So there is no directory in the end. Only the DNS system and everyone knows how to calculate the same hash out of an identifier. So it’s just rules that have been agreed on.
This is how the real Peppol lookup actually works and is the only thing what matters when lookups are done.
Any directories or listings are just extra that tries to make the lookup more human friendly.