Solution for Rubik’s Cube of E-Invoicing in SAP Document and Reporting Compliance

[smirnov_mikhail]

Hello, my name is Mikhail Smirnov and I’m seasoned FICO SAP consultant who, in recent years, has also become an E-Invoicing enthusiast and professional. During last six years I’ve had the privilege to work as Integration Architect on compliance projects in different companies and countries, with different providers and technologies integrated with SAP. As well I participated in solution selection process for different countries. In general, it is easy to conclude that E-Invoicing is an umbrella term.

That’s exactly what Wiki says as well. However, it is not informative and tricky for understanding, especially by people new to the topic. That’s why I decided to write this article, to quantify this general term into clear and measurable characteristics. These characteristics can be learned one by one, checked in needed e-invoicing model and matched with the functions of SAP Document and Reporting Compliance. In my understanding it is essential precondition to plan and deliver successful e-invoicing solution.

There are no two countries with the same e-invoicing regulation. E-invoicing models in different countries have unique composition of different processes in scope, technological frameworks, local service provider required by law or are optional to work with (but additional value), local language requirements etc. It means, that context is essential when we talk about e-invoicing, what country is it, which process do we discuss etc.

It slightly reminded me of the term “Account” in SAP. It can be a G/L Account, Customer or Supplier Account, or even Business Partner Account in S/4HANA, and finally Bank Account, but this Account is also split into House Bank Account and Bank Account Master Record. I remember how I was reading courses in the beginning of my SAP journey and sometimes felt absolutely lost, which account it is.

In addition to the Account term, I’ve heard a couple of much stronger metaphors in the latest SAP DRC Summit to depict the diversity in global landscape of e-invoicing. We can compare e-invoicing with kaleidoscope or Rubik’s Cube to emphasize the countless range of permutations in e-invoicing models. The common things in all these models are pursuing digitalization and transformation of the business.

Another mission critical goal is improvement of VAT collection. The overall EU VAT Gap was estimated in nominal terms as 99 billion € in 2020 and as 61 billion € in 2021 (COVID could also influence this change). Italy, where all invoices are subjected to e-invoicing, is considered as the most advanced European country in e-invoicing. Roughly 4 billion € p.a. are recovered there.

Pursuing all these goals every country has its own digitalization roadmap of e-invoicing and is regularly changing it. Sounds tricky indeed, when we compare e-invoicing with kaleidoscope you can just enjoy beautiful pictures. However, Rubik’s Cube is different story, there are practical algorithms to solve it. Exploration of this algorithm through definition of e-invoicing characteristics and their mapping to the functions of SAP DRC is the goal of this article. It will also help us to answer the pivotal question of newbies in this area, what is e-invoicing in general? Let’s begin our exercise with the characteristics:

1. Common features in all e-invoicing models still exist, these are:

• Data is obtained directly from business transactions in real time or near-real time before local e-invoice submission deadline is breached.
• E-invoice transfer begins from the transactional system of economical agent, usually seller.
• Any e-invoice presents data in a structured machine-readable format. It allows quick and efficient processing by computer systems.

Electronic invoice (e-invoice) has nothing to do with digital invoice. Typical digital invoices are PDF invoices and paper scanned invoices, which are not machine-readable like XML e-invoice.

However, some e-invoicing mandates combine electronic invoice and digital invoice into PDF/A-3 format (human readable PDF with embedded XML structure). Such example is used in Saudi Arabia, where SAP DRC can embed digitally signed XML into SD PDF based output form and update it after submission with QR Code and Digital Signature assigned by local tax office.

That’s all about similarity, next points are about differences.

2. Formats and schemas.

There is a long list file of formats used in e-invoicing: XML, PDF/A-3, EDIFACT in EDI, CSV, JSON, and more. Formats present here a high level overview. Every country selects not only formats to be leveraged, but also which syntax (schema or standard) will be used inside the file. As example we can take the one of the most common e-invoicing formats XML and check syntaxes per country:

• Kingdom of Saudi Arabia: UBL 2.1 format in XML is used there. The same format is used in the Peppol network, but in Saudi Arabia it is used without Peppol network and send through API from issuer to local tax office. This format is adjusted accordingly to local rules and business requirements and is called FATOORAH e-invoice.
• Italy:  national XML standard FatturaPA is used. It is sent through API to local tax office.
• Germany: multiple e-invoicing platforms and formats exist in Germany, their multitude is called E-Rechnungen. The main formats are Xrechnung, XML with UBL syntax for Peppol network, ZUGFeRD combining unstructured PDF image and structured XML in CII syntax into one PDF/A-3 e-invoice file for email distribution and other national country formats. The most common formats are Peppol and ZUGFeRD and both are delivered in SAP DRC (Fig. 1.). Sometimes they are also referenced as types of XRechnung. Because these are two different formats, SAP delivers solutions for them in two different country extensions of SAP DRC for Germany. Each country extension consists of separate packages of notes, customizations, connections etc. Installation of Peppol country extension is a prerequisite for installation of ZUGFeRD country extension.

Fig. 1. E-invoicing formats in Germany referenced as XRechnung types and realized in SAP DRC (marked with blue and yellow).

3. E-invoicing models based on national standards and frameworks (non-Peppol).

These standards and frameworks (exchange systems) usually originates from the local Tax Office initiatives and mandates. Their goal is implementation of Continuous Transaction Control (CTC) regime to report taxes from operational business transactions (invoices) directly to the Tax Office on-line, almost on-line or within short period of time.

That’s where machine readable files (i.e. XML) generated from invoices become instrumental. Tax offices validate XML files and if file is correct, then perform procedure called Clearance, it is when XML file is e.g. digitally signed, sealed, QR-codded, encrypted to protect it from tampering, VAT is reported both for seller and buyer and just at this point of time XML file becomes true legal electronical invoice (e-invoice). As far as VAT is already reported both for seller and buyer during successful clearance, e-invoice is obligatory for posting by customer. All subsequent corrections are performed by debit or credit memos. CTC is relatively new approach opposing to periodical reporting regime realized in monthly, quarterly, or annual reporting.

Main limitations of national CTC standards is missing communication between countries. As well communication with partners through local framework is not a must, it depends on the mandate. Examples of national standards and frameworks are:

• FATOORAH e-invoicing in the Kingdom of Saudi Arabia submitted to FATOORA Platform of the local tax authority ZATCA. This platform currently doesn’t provide exchange between seller and customer. Cleared e-invoices marked with the digital signature and QR Code are sent to customer per email.
• FatturaPA format in Italy submitted to exchange system SdI of the local tax authorities, FA Invoice format in Poland submitted to KSeF portal of the local tax office. Both platforms support exchange of e-invoices between seller and customer. Customers are allowed to post purchase invoices from e-invoices. That’s where standard integration between SAP DRC and SAP Business Network (Ariba) or Vendor Invoice Management (VIM) is essential to automate postings from inbound purchasing e-invoices.

SAP Document and Reporting Compliancedone deploys connections to local tax office platforms in SAP Integration Suite cloud. The DRC architecture comprising this component is depicted in the Figure 2, where SAP Integration Suite cloud is a grey box. There are two exceptions not deployed in the SAP Integration Suite. These are connections with national Polish KSeF and Romanian e-Factura platforms. We will discuss it later. 

Fig. 2: SAP Document and Reporting Compliance Architecture.

4. PEPPOL e-invoicing model.

Peppol network grows from a pan-European e-procurement initiative. Its goal is global interoperable transfer of e-documents. Specification of Peppol is called Business Interoperability Specification (BIS) and XML format is called Universal Business Language (UBL). Different countries create local variants of Peppol and leverage it as a driver of economy digitalization.  

Access to Peppol network is done usually through providers offering Peppol Access Point (AP). Such communication between two partners, each connected to own Peppol access point is called 4-Corner model, it is depicted in the Figure 3.

Fig. 3. Peppol 4 Corner model.

Peppol 4-Corner e-invoicing model is not considered a CTC model, because it doesn’t involve local tax authorities. Even though Peppol e-invoicing is mandatory in some countries (e.g., Sweden, Finland, Norway). Peppol model was Initially focused on B2G e-invoices in EU, but now it is growing in every dimension country by country adding:

• B2B, G2B, G2G e-invoicing,
• E-Catalogue, e-Orders, e-Delivery Notes, e-tendering and so on,
• New corners. 5-Corner and 6-Corner models were introduced, where 5th and 6th Corner stay for tax authority and Access Point of tax authority. It converts just an e-invoice exchange between partners into CTC model. 5-Corener model is illustrated in the Figure 4. OpenPeppol working group promoting this initiative and it includes leading experts in the industry,
• Moving beyond Europe into Singapore, Australia, New Zealand, the US, Mexico, South Africa, and more
• New international Peppol standard PINT (Peppol International Invoicing Model) is in development to connect all this countries and local tax authorities within CTC 5-Corener model. Design of this standard allows to meet international requirements and add local specifications. Japan is the first country to develop Peppol e-invoicing model based on PINT.

All points listed above make Peppol one of the most forward-looking solutions for international e-invoicing.

Fig. 4: Peppol CTC model with 5-Corners, where 5th corner C5 stands for local Tax Authority.

SAP DRC provides Peppol Access Point in the Peppol Exchange service of the cloud called SAP DRC Cloud Edition. Its place in the SAP DRC architecture is depicted in the Figure 2 in the blue box. SAP DRC Cloud edition is not an alternative to SAP DRC on-premise (Back-End system), but a cloud integrated with SAP DRC on-premise. In general suffix “on-premise” is gone now from the SAP DRC Back-End system name, because Back-End system can also be cloud, i.e. SAP S/4HANA Cloud. Yellow box on the left in the Figure 2 reflects these options and new naming convention.

Conclusion for points 3 and 4 is, that SAP DRC has two integration models through SAP Integration Suite or through DRC Cloud Edition. In each country only one model can be utilized. You can check it in the Supported Compliance Tasks by Country/Region SAP page in the column Supported Submission Type.

New version of the SAP DRC Cloud edition (Cloud Foundry environment) goes beyond Peppol Exchange service. It is expanded to become a central hub connected to different platforms and networks. It already provides connection to Polish KSeF and Romanian e-Factura national non-Peppol platforms. DRC Cloud edition new version has a new approach of Ready-to-use services with reduced efforts for the integration.

SAP will add new and move over time existing connections of national e-invoicing platforms from SAP Integration Suite to DRC Cloud Edition.

5. VAT in the Digital Age or simply ViDA.

ViDA is an initiative of European Commission intended to reform the European Union (EU) Value Added Tax (VAT) system. It consists of three pillars focused on digitizing and building transparent and compliant VAT taxation system:

• A move to mandatory real-time digital reporting based on e-invoicing for businesses operating cross-border in the EU. I.e. recapitulative statements filed to VIES (VAT Information Exchange System) will be abolished,
• VAT treatment of the platform economy obliging transport and short-term accommodation platforms to collect and remit VAT to tax authorities when their users do not,
• The introduction of a single VAT registration across the EU (sounds like Plants Abroad functionality of SAP can become excessive)

The EU Commission estimates that moving to universal e-invoicing will help recoup up to €11 billion in lost VAT revenues a year, businesses will bring down administrative and compliance costs by over €4.1 billion a year over the next ten years.

E-invoicing in ViDA reality must comply with the European standard on e-invoicing. It includes UBL (Peppol) and CII (i.e. ZUGFeRD) syntaxes. Many European countries already build their e-invoicing models compliant to that standard (Peppol UBL standard and BIS specification), but still radical implications are foreseen. The most obvious are extension of Peppol B2G country mandates to B2B and B2C and implementation of 5th Corner (Tax Offices) into Peppol models.

ViDA is mentioned here not as characteristic of e-invoicing tools, but as an accelerator for subjected countries to introduce, adjust and extend e-invoicing mandates. Definitely, there will be a strong demand for respective changes in all e-invoicing tools. SAP DRC team is in a very good shape to cope with this challenge. Their backlog of processed new regulations per year increased more than 4 times as of 2020 (Fig. 5.)

Fig. 5: amount of backlog items for SAP DRC due to legal changes.

6. Reporting models

There are quite many different words with prefix “e” today. Let’s put aside things obvious from the name like e-order or e-delivery and check for reporting models mandated in legal statutes and defining what, when and how is transmitted to the tax office. SAP developed excellent slide (Fig. 6.) showing development of these regulation models from paper-based till the highest level of automation in E-verify stage.

Fig. 6. evolution of reporting regulation models.

Let’s discuss what these models mean except two ancient ones in the beginning of the timeline:

• E-File – it is manual input of tax information in an on-premise software or online portal. Once tax declaration is ready user can transmit the data electronically (e-filling) or print and mail.
• E-Audit – is focused on the ability to export accounting data subjected to audit to a specific format. Specifications and guidelines of Standard Audit File for Tax (SAF-T) is an example of E-Audit approach. SAF-T as a concept was developed from an audit perspective and from technological perspective SAP delivers SAF-T tools for different countries. SAF-T files have strict formats and rules in each country, where they are implemented.
• There is another approach materialized in Data Retention Tool (DART) in SAP. Data extraction in it can be customized accordingly to requirements of government tax audits in every country considering also additional requirements of every company. Simply, it downloads selected tables from SAP into flat files, which auditors can check in their software. E-Invoicing – in the Figure 6 just an E-invoicing models stands for non-CTC e-invoicing, e.g. Peppol 4-Corner model without submission and clearance of the tax data in local tax authorities.
• E-accounting – is an extension of E-audit approach. Extension means, that tax authorities can request information proactively or on-demand, data transfer is performed as a ‘push’ report through a predetermined digital channel. Tax authorities leveraging this model strive to possess at any time a copy of all relevant business data for audit and tax calculation in their systems. This way they perform auditing of both direct (income) and indirect taxes. SAF-T regulations are now adopting this model and cover the ‘full set’ of business and accounting records commonly held by taxpayers. The standard includes the following datasets: General Ledger; Accounts Receivable (master data and invoices); Accounts Payable (master data, invoices, and payment); Goods movements; Fixed assets; Inventory.
• Another example of leveraged E-accounting model is myDATA e-Books in Greece comprising both CTC E-invoicing and E-accounting. This mandate will be discussed later in this article.E-clearance + distribution – this model was already explained above together with the definition of Clearance. Italian and Polish e-invoicing models were given there as examples of e-invoice clearance by tax office and distribution to the recipient of e-invoice.
• E-verify – in this model tax offices are moving toward calculation of VAT Returns from e-invoices. This stage is estimated as the highest level of automation.

7. Architecture of e-Invoicing and CTC models

Although every model is country specific and has unique design, it is still possible to group them by architecture from a bird’s eye view. Differences in models is defined by involved parties and information flow between them. Figure 7 below perfectly illustrates different models highlighting with the green color regulated CTC exchange where VAT is reported to a tax office. Blue color illustrates standardized e-invoice exchange in mandated formats, but without reporting to tax offices, hence non-CTC exchange. Numbers on the schemas explain the order of exchange interactions.

Fig. 7: e-invoicing exchange and CTC models. E.g. Peppol 4-Corner model is seen here in Interoperability box.

Also, you can meet another naming approach, V and Y models. V stands for schematic naming of Centralized Exchange model and Y stands for Decentralized Exchange model. Correlation between “Y” and the picture of Decentralized model is: supplier and vendor are in the top ends of “Y”, tax portal and tax office are in the bottom point of “Y”, 3rd party providers of software solution are in the middle connection point of “Y”.

Placing 3rd party providers in one point means, that providers of customer and supplier perform exchange of e-invoices with each other independently from the e-invoice clearance in the tax office. Great example of Y or Decentralized model is France. French e-invoicing mandate allows connect to the government portal Chorus PRO directly or through optional 3rd party providers. Connection to Chorus PRO is free, but it can receive only e-invoices in appropriate XML format. Hence, you must generate XML e-invoice yourself or by means of 3rd party providers.

Previously SAP DRC had strict approach to connect with local e-invoicing portals only directly without any 3rd parties in between. However, now it is not the case anymore. Recently connection from SAP through intermediate provider is allowed in France, Poland, and Türkiye. It adds flexibility to the solutions and allows companies archive desired architectures.

8. E-invoicing and e-reporting

Another umbrella term in this industry is E-Reporting often accompanying E-Invoicing. It is seen as part of E-Invoicing, that’s why it is not explicitly depicted in the Figure 6. Both models e-invoicing and e-reporting have in common the same file format and syntaxes, the same submission channel to the same tax platform.

Specialty of e-reporting is, that it stands for submission of documents (processes) to local tax offices which:

• can’t be cleared during submission, i.e. VAT can’t be reported simultaneously both for seller and buyer,
• can’t be forwarded through the framework to a receiver,
• usually have much longer submission deadline than e-invoicing and can be submitted in batches.

Typical examples of e-reporting are export and import invoices, B2C sales invoices. Both foreign companies and B2C customers don’t have connection to local e-invoicing framework, hence can’t submit or receive e-invoice in machine readable format. However, for example in the Kingdom of Saudi Arabia B2C customer can optionally scan QR code on paper invoice and verify invoice authenticity by local tax platform.

SAP has provided very clear explanations and examples for e-invoicing and e-reporting in France in the Figure 8 below.

Fig. 8. French Regulation for E-Invoicing and E-Reporting

Many countries recently have clearly defined both terms e-invoicing and e-reporting in their mandates and frameworks the same way as explained in the Figure 8.

Special case is Italy with one of the oldest e-invoicing frameworks in Europe. Export and import invoices were included there in the e-invoicing mandate as of 2022 before e-reporting term became so common. That’s why they are referenced as e-invoicing in all the sources, although they fully match with e-reporting definition.

As far as e-reporting and e-invoicing goes through the same channels in the same formats SAP DRC easily fulfills both models.

9. Different e-invoicing frameworks in one country.

We’ve mentioned above in the point 2, that e.g. Germany has different e-invoicing models and frameworks delivered in different country extensions of SAP DRC. That’s not the only example. Poland has two e-invoicing frameworks mandated by tax authority:

• New B2B mandate previously announced coming into force in 2024 and materialized in electronic invoice exchange through the National System of E-Invoices (KSeF) in national XML format FA Invoices,
• B2G mandate implemented via Peppol in the Platform Elektronicznego Fakturowania (PEF). It will be integrated with KSeF in 2024. After this integration there will be a choice to submit B2G e-invoices through KSeF or continue submitting through PEF.

SAP has depicted both frameworks on the Figure 9 below.

Fig. 9. Data flows of two Polish e-invoicing mandates in SAP DRC architecture.

Much tricker situation is in Greece. As of 1st of January 2024 new legal mandate and technical framework are effective in Greece to perform B2G e-invoicing in Peppol network. New mandate replaces outbound B2G part of previous Greek e-invoicing mandate and framework called myDATA e-Books. Previous mandate comprises not only CTC part with inbound and outbound e-invoices for VAT clearance and reporting, but also submission of Profit and Loss (depreciation, FX revaluation etc.) data for Profit Tax reporting and withholding tax.

That’s why in addition to CTC e-invoicing model myDATA e-Books also include eAccounting model. All other components of previous myDATA framework except B2G are still in force. E-invoice format of the new Peppol mandate contains all the same local mappings and rules as in the previous myDATA mandate. Also new Peppol framework leverages 5-Corner model connected to the same myDATA tax portal to perform the same clearance and VAT reporting as before.

It can be seen as preparation for ViDA reform through e-invoicing mandates unification and transition from national e-invoicing model to Peppol technology. myDATA e-Books solution is fully delivered in SAP DRC, however new mandate allows connection to the new B2G framework only to local providers. Hence, such connection directly from SAP DRC is not possible unless regulation changes and companies in Greece must take care about this solution themselves.

Local Greek providers developed new respective framework to support new Peppol mandate. New framework allows to local providers also process and submit B2B and B2C invoices to the myDATA tax portal and stay 100% compliant. Hence, practical approach here is to extract all sales invoices from the old framework and allocate them to the new framework letting provider control e-invoicing flows. Provider will report all sales e-invoices upon receival to myDATA and after successful clearance will send B2G e-invoices through Peppol network and B2B/B2C e-invoices per e-mails to receivers. Such an e-mail distribution is called e-billing in Greece.

Later upon extension of the new Peppol mandate to B2B and B2C local providers will redirect flows of B2B and B2C e-invoices from e-mail distribution to Peppol network itself without your involvement. However, extension of new mandate to B2B will mean, that receival of e-invoices through Peppol network will begin for you and it will require implementation of respective e-invoicing inbound process.

10. Scope of Outbound E-Invoicing processes.

From the name Outbound E-Invoicing process seems, that this must be only sales. However, outbound stands here not for sales, but for the fact that your system is the source of e-invoice, and you submit it to the tax office. Furthermore, there are such processes in purchasing when you generate and submit e-invoice:

• We’ve discussed above e-reporting process for import. Foreign companies are not connected to the national e-invoicing frameworks and can deliver invoice to you only as usual. Then purchase import invoice is posted as usually and at this moment e-invoice is generated, which you can submit to the tax office. As discussed, import process is called e-reporting, because there is no connection with partner through the local e-invoicing framework. In Italy both import and export completely match with today e-reporting definition, however they are still referenced there as e-invoices.
• Self-billing in purchasing when buyer issues and submits invoice on behalf of the seller. For example, buyer has a contract with seller to receive deliveries on the regular basis and then issue a purchase invoice on behalf of seller for the total of deliveries, when agreed amount is reached. Usually, this process is realized in standard SAP functionality called Evaluated Receipt Settlement (ERS) feature. Respective Purchase Orders are created with ERS flag activated. This process is accounted in DRC outbound e-invoicing scope as well and Figure FF depicts it in the Kingdom of Saudi Arabia

Fig. 10. Outbound e-invoicing process in the Kingdom of Saudi Arabia through local tax office ZATCA including self-billing in purchasing.

11. Changes in cancelation (reversal) processes imposed by e-invoicing statutes.

Invoice submitted and cleared by tax offices can’t be cancelled (reversed) because taxes are reported. Hence, cleared invoice is also obligatory for posting on the receiver side. All together it means, that any correction of such invoice is allowed only by credit or debit memos. However, before submission and clearance can be differences, let’s check for a couple of examples:

• In Polish KSeF B2B framework you still can cancel sales SD Billing document until it is released to FI. I.e. posting to accounting is point of no return in Poland.
• In Greece you can release sales SD Billing documents to accounting. The point of no return is execution of local Hellenization report, which assigns Hellenic Number and Series to sales invoices. As far as Hellenic data is assigned, submission of e-invoice is mandatory. Before Hellenization you still can cancel Billing documents.
• In Italy the main requirement is to have sequential numbering of invoices and e-invoices. As far as FI document number is used as e-invoice number in SAP DRC, great help is assignment of independent number ranges in SD Billing and respective FI documents. Usually, FI has external number ranges for invoices posted from SD, i.e. their numbers are inherited from SD Billing document. Having independent numbering you can easily cancel erroneous billing document not released to FI and keep FI numbering sequential without gaps. Following requirement to have FI document number in SD invoice printout is relatively low cost to fulfill sequential numbering requirement.

Sometime there is no way to fix content of erroneous invoice and respective e-invoice or fix will take too long. Hence, you still need cancel invoice or post corrective credit memo not submitting both. Then you need again post invoice with correct data for proper submission. Doing such corrections of sales documents, you will get gaps in SD and FI document numbering, which can cause questions from auditors and tax offices. That is why such situation must be clarified with local auditors first and better in advance. Probably just a proper documentation of such cases in paper or/and electronical archives for the future audits will be sufficient.

12. Different requirements in e-invoicing mandates depending on establishment or resident status.

This point also has wording specific depending on country. Let’s check for two examples:

• In Romania non-established taxpayers with VAT registration numbers in Romania must comply with the e-reporting obligation and established taxpayers must comply with the e-invoicing obligation.
• In Poland non-resident taxpayers registered for VAT in Poland will be obliged to issue invoices in KSeF only in case they have permanent establishment for VAT purpose in Poland.

Key criteria in both examples above is that both non-established and non-resident taxpayers have VAT Registration (VAT ID) in these countries, but they are established and have residency in some other country. From SAP perspective both cases non-established and non-resident status of taxpayer is realized in Plants Abroad Functionality, where Company Code is registered and assigned to one country but can have multiple VAT registrations (VAT ID) in other countries.  

13. Other characteristics of e-invoicing.

Above are explained the most important characteristics to my mind. They are discussed one or another way in every e-invoicing project I was involved. Here are also some I could briefly mention:

• Scope of processes: B2G, B2B, B2C, G2G, Export, Import, Down-Payment Invoices, Self-billing invoices in purchasing, etc.
• Legal obligation to archive e-invoices. Specific format and digital signature of archive can be mandated.
• Onboarding process at the tax office. It can be fully automated process in SAP for Saudi Arabia or tricky procedure including mandatory successful e-invoice exchange through test connection channel in Italy.
• Capability to embed your own PDF forms into XML e-invoice like in Italy or Poland.
• Implementation of mandate in waves depending e.g. on the turnover of companies.
• Multitude of other characteristics…

Conclusion

All this is a small part of possible differences in e-invoicing models. Legal experts analyzing these mandates differentiate there more than two hundreds of research categories different from country to country (Fig. 11.). For sure it creates countless permutations which make you feel dealing with kaleidoscope or Rubik’s Cube. This article explains relatively small number of characteristics, but I suppose they play pivotal role in understanding of differences in e-invoicing models. Going through these characteristics for a particular country and matching them with needed components and functions of SAP Document and Reporting Compliance you can build a respective solution. That’s how you can solve e-invoicing Rubik’s Cube for needed country planning and executing the project accordingly.

Fig. 11. Amount of E-Invoicing research categories distinguished by legal experts in Sovos company.

After solution is built you can notice that some pieces of Rubik’s Cube can change their colors. It happens due to local and global legal initiatives, technological changes, and upgrades on your, provider, and tax platform sides. It means, that even after successful implementation of the e-invoicing project bumpy ride is not accomplished. That’s why E2E understanding of this topic is needed within your organization. It will let you establish efficient communications between all these parties to learn subsequent changes together and deal with them timely, also to transfer knowledge and perception of the big picture between colleagues.

In writing this article, I tried also to show use of synergy in the industry and advantage of learning from different sources. In general, this industry is very vivid with local specific from all around the globe and multiple solution providers. In addition to this some companies have their internal vocabulary. Therefore, some differences in wording and definitions are possible, and several examples were clarified in this article. Important is to align understanding and come to the right conclusions before the project begins.

That’s the main responsibility of the Integration Architect to possess E2E understanding of the e-invoicing model being considered, align understanding of all the parties involved, and execute or being involved in all the project activities. 

Compliance topic in general and e-invoicing topic in particular is on the rise, more and more companies are facing this challenge, and market is growing respectively. Therefore, I hope this article will be helpful in this area.