Many software packages advertise it: “we talk UBL and so we can e-invoice”. The reality is more stubborn, and many users run into the fact that “talking 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 error-free. We therefore often encounter in practice that the software package has a different interpretation of the UBL, and therefore the e-invoice cannot be read by the recipient. Some software packages are certified, providing more guarantees about the reliability of the UBL.
2. One ubl is not the other
There are several dialects within UBL and many software packages have implemented their own dialect, which then often cannot be fully read by a receiving package. The most commonly used UBL “dialect” is the SI-UBL.
3. The delivery channel of the e-invoice is important
There are an increasing number of recipients who want to receive their invoices through a secure and reliable network (Peppol). This requires that the sending software package must support this method of invoice delivery. Not every software package does this yet. Therefore, many software packages that do “ubl talk” still cannot e-invoice to the government, and other large senders.
So for invoice senders using software that cannot yet deliver Peppol invoices, an additional solution is needed. Click here for the solutions we offer for this.
