Many software packages advertise with it: "we speak UBL and so we can e-invoice". The reality is more difficult and many users run into the fact that speaking UBL is not enough to deliver invoices, for example to the government. Why is that?
There are 3 main reasons:
1. Different interpretations in the implementation of UBL
Not every implementation of UBL is flawless. In many cases, therefore, the software package has a different interpretation of the UBL, which means that the e-invoice cannot be read by the recipient. Some software packages are certified, so there are more guarantees about the reliability of the UBL.
2. One UBL is not the other
There are different dialects within UBL and many software packages have implemented their own dialect, which often cannot be fully read by a receiving package. The most commonly used UBL 'dialect' is that of Simplerinvoicing, but not every package supports the Simplerinvoicing UBL (SI-UBL).
3. The delivery channel is important
More and more recipients want to receive their invoices via a secure and reliable network (Simplerinvoicing-FULL or PEPPOL). This requires that the sending software package must support this type of invoice delivery. Not every software package does this yet. Therefore, many software packages that do talk 'please' still cannot e-invoice to the government, and other large senders.
For invoice senders who use software that is not yet able to issue Simplerinvoicing/PEPPOL invoices, an additional solution is therefore needed. Tradeinterop provides this link. We do this as follows:
Mail an UBL and a PDF from your software package to the Tradeinterop platform.
Tradeinterop converts the invoice into a format that the recipient can read.
Tradeinterop delivers the invoice on the channel where the recipient wants it.
To do this, the sender needs an account on the tradeinterop portal: this can be created on portal.tradeinterop.com.