eInvoice – a modular integration design approach

Electronic data transfer is nothing new. But still there is a significant amount of invoices sent traditionally via PDF or even paper. To solve this, there are several initiatives to increase the amount of digitally sent invoices. The European Union decided to leverage the use of electronic invoices starting from January 2025: The public sector and enterprises in B2B are required to use only electronic invoices that comply with EN 16931.

This standard requires invoices to be in XML format and to comply with a standard data model. Currently, there are two XML formats that conform to this standard: CII (by UNECE) and UBL (by OSiG). Both are valid implementations of the standard which requires that a company be able to process either of them. Companies have a choice, though, when it comes to sending invoices. They do not have to send both versions – one is sufficient to send, since the receiver must be able to accept either.

Other non-EU countries take a similar approach, and this leads to many other (standard) formats coming into play. As a result, companies have to deal with various formats for sending or receiving, so solutions need to be very flexible in the input and output formats. Consider a company that has branches in several countries. They will have to deal with many invoices formats, several ways to receive invoices, several ways to send invoices, several systems processing the invoices and several systems to archive the originals.

Architecting a Solution

To solve this complex issue, we suggest creating a highly modular solution so that you can adjust every step according to the needs of that particular branch and customer.

Let’s have a look at the receiving part: First you need to receive the invoice, then you need to archive it. Afterwards, you want to validate the input and transform it into some intermediary format. Finally, you want to transform the data into the target format and process it with the target system.

The sending part looks quite similar: First you want to receive the data from your invoicing system, then you want to transform the data into the intermediary format. After this you want to transform the intermediary data format to the final format suiting your branch and customer. The next step is to archive the invoice before finally sending it out to your customer.

Finding the modules is quite easy: just create one module per step. Doing so let’s you read from different inputs, transforming from and to any format, use different archiving systems and sending to different systems as well.

Using the intermediary format is important in avoiding having to map every source format to every target format which would end up in n*m mappings. With the intermediary format it’s only n+m mappings with n= the count of source formats and m= the count of target formats. With n=4 and m=4 the comparison is 16 mappings vs 8 mappings. And the number of formats will be higher than this in real world.

Let’s have a look at the modular design from a more technical perspective. Remember that you can combine any process of one module with each of the other modules. By this design you get full flexibility in your processing:

Inbound modules (from the customer)

1. Receivers: get the data by email, sFTP, …
2. Archivers: save the invoices to a DMS
3. Additional processors or pre-processors: unpack the data (e.g. from a PDF/A3)
4. Source transformers to intermediary format mappers
5. Target transformers Intermediary format mappers
6. Senders: the invoice creators

Outbound modules (to the customer)

1. Receivers: get the invoice data
2. Source transformer to intermediary format mappers
3. Target transformer Intermediate data to target format mappers
4. Additional processor or post processor: pack the data (e.g. into a PDF/A3)
5. Archives: save the invoices to a DMS
6. Senders: send the invoices by email, sFTP, …

Remark: the source to intermediary format mappers in- and outbound are not the same since they work in the opposite direction.

If you use these modules in the integration platform of your choice, you have the flexibility to add new source and target systems as well as new formats easily. Only make sure that the modules have clear interfaces between each other.

At Apps Associates, we’re proud to be a trusted Oracle implementation partner, helping businesses successfully navigate every stage of their digital transformation. Whether you found valuable insights in this post or want to explore more about the topic, we’re here to guide you. From strategy and deployment to ongoing support, our expertise ensures you have a partner you can rely on to achieve your goals. If you’d like to learn more about how we can assist your business, feel free to contact us today.