As a few Brazilian tax experts met in 2004 within the frame of the National Meeting of State Tax Coordinators and Administrators (Encat), none of them expected that their ideas would turn around auditing practices in the rest of the world. Brazil introduced the Nota Fiscal eletrônica (NF-e) in 2006. It resulted in an estimated drop of 50% in tax evasion and a plus of 30% in tax collection[1]. These results triggered a global wave of tax laws whose effects are still being felt, with more countries adopting the same each year.
Unfortunately, even today, no ISO norm or golden rule is available to governments to define their auditing processes. Each government starts with own thoughts, does look at the best practices of others, but in the end focuses on own specific issues. This has led to the creation a wide range of implementations by individual nations. Even the tiniest jurisdictions have come up with their own document definitions, own concepts for document numbering, for clearance, distribution, printing and archiving.
Many businesses have centralized billing and other administrative tasks in global shared service centers. Such transversal functions try to keep harmonized processes across geographies to lower costs and complexity. Constantly changing and diverse tax requirements put their operations under tremendous pressure. To address this issue, SAP developed SAP Document Compliance (also known as eDocument). As of February 2020, the solution is available in SAP S/4HANA Cloud and, along with SAP Cloud Platform Integration, it supports local end-to-end electronic processes in 12 countries. More countries and processes are to follow.
The geographic coverage of SAP S/4HANA Cloud now includes Starter Packs. These will help partners and customers extend S/4HANA Cloud to support local requirements (more details in this blog). As of now, none of these Starter Pack jurisdictions mandate electronic exchange by law. Nevertheless, going forward, the global wave of tax laws is likely to hit them too. Some countries, such as the Dominican Republic are already taking steps in this direction. That makes it compelling to have something like a check list to assess electronic document mandates.
The below drawing attempts at illustrating a possible analysis framework.
Assuming a classical business transaction, the drawing represents a simplified process of potential touch points between a buyer, a supplier, a transporter and a government. In the diagram, the process is simplified, the sequence could be different, steps are missing such as the actual delivery, industry specificities are not considered, and self-billing would be a topic for itself. However, all in all, the illustration provides a map to start the journey. Let’s walk through it.
The process starts with the creation of a purchase order by the buyer (B00) and of a corresponding Sales order at the supplier (S00). These steps are typically not reported to authorities, hence the grey boxes at G00 and G01. We also skip merchandise preparation to arrive at the creation of a transport document (S02). For government auditors, the purpose of transport documents is to facilitate tax-related controls during goods transportation. The police can stop trucks on the road and check that their loads have been properly declared (G11). To enable that cross-checking, a reference to the transporting vehicle is mandated in the electronic documents (S02 or S03). If transport is initiated by the buyer (B02), then the buyer might have to create transport registration (B02) and/or transport documents in place of the supplier (B03).
The next steps deal with the invoice itself.
A unique identifier of invoices is key to the data quality of government platforms. Therefore, they require more than the simple invoice numbering provided by accounting systems. Instead or in parallel, an Official Document Number (ODN) is expected. Here also, several approaches co-exist. A government agency can provide each business with a range or list of pre-assigned billing numbers. During billing, clerks then tip in or copy ODNs from the lists or get them assigned from a built-in sequence by their accounting package. The list itself can take several forms : e-mail, PDF, Excel, XML, Webservice, etc. A reversed approach to ODN also exists, businesses create the ODN themselves and register (or clear) it with the government platform. This is represented by the double arrows between S04 and G04. The sequence of ODNs and the possibilities to cancel documents are extra attention points as they might impact the ability to ship and bill whenever a mandatory sequence is broken. Businesses also have to report exceptions and gaps in their usage of ODNs. This can be done in specific monthly reports or in government portals.
Similarly, businesses might be required to register invoice details (S05 and G05). In some countries, the government platform even distributes the invoice to the buyer (G06 and S06). The requirements, in that case, can include the following:
Here, it’s also important to look at the type of invoices in scope, for example:
Some countries consolidate invoice and transport documents to one document. Transport information is then a mandatory content of invoices and invoice copies are given to the transporter (T06) to enable road controls. Specific print forms for transport documents (S03) and/or invoices (S06) might be required. They typically include QR-codes to simplify road controls and other audits.
Archiving is the last step of the billing process (S07 and B07). Local archiving or locally certified archiving providers might be a requirement.
In countries where electronic documents are mature, like in Mexico, the payment process might be mandated too (B08, G08, and S08).
After the fact, transactions often have to be reported e.g. in VAT or sales-tax reports or via standard accounting files (aka SAF-T). In this case also, double arrows are relevant as businesses might be required to validate the reports that governments have created for them. In some other cases, governments deprecate these reports after the introduction of mandatory electronic invoicing.
As a last step along the map, the data available on the government platform is used to spot suspect transactions (G12) and trigger onsite audits (G10, G13).
These are the attention points to analyze electronic document requirements. The source for such information is typically a website operated by the local ministry of finance. In the evaluation process, your organization should involve tax experts and internal and external auditors.
Knowing the dynamics of change in tax laws helps predict the chain of events and plan ahead of time. Typically, governments introduce mandates in this sequence:
The introduction plan might combine some phases, but the overall sequence typically remains.
Dealing with mandatory electronic documents sometimes feels like a journey without a finishing line. We hope that the above map will help along the way.
[1] Bruno Koch, Billentis, The e-invoicing journey 2019-2025, page 19.
PS: Within SAP S/4HANA Cloud implementations, the most relevant scope items for the topic under discussion in this blog post include the following:
Unfortunately, even today, no ISO norm or golden rule is available to governments to define their auditing processes. Each government starts with own thoughts, does look at the best practices of others, but in the end focuses on own specific issues. This has led to the creation a wide range of implementations by individual nations. Even the tiniest jurisdictions have come up with their own document definitions, own concepts for document numbering, for clearance, distribution, printing and archiving.
Many businesses have centralized billing and other administrative tasks in global shared service centers. Such transversal functions try to keep harmonized processes across geographies to lower costs and complexity. Constantly changing and diverse tax requirements put their operations under tremendous pressure. To address this issue, SAP developed SAP Document Compliance (also known as eDocument). As of February 2020, the solution is available in SAP S/4HANA Cloud and, along with SAP Cloud Platform Integration, it supports local end-to-end electronic processes in 12 countries. More countries and processes are to follow.
The geographic coverage of SAP S/4HANA Cloud now includes Starter Packs. These will help partners and customers extend S/4HANA Cloud to support local requirements (more details in this blog). As of now, none of these Starter Pack jurisdictions mandate electronic exchange by law. Nevertheless, going forward, the global wave of tax laws is likely to hit them too. Some countries, such as the Dominican Republic are already taking steps in this direction. That makes it compelling to have something like a check list to assess electronic document mandates.
How to analyze electronic document requirements?
The below drawing attempts at illustrating a possible analysis framework.
Assuming a classical business transaction, the drawing represents a simplified process of potential touch points between a buyer, a supplier, a transporter and a government. In the diagram, the process is simplified, the sequence could be different, steps are missing such as the actual delivery, industry specificities are not considered, and self-billing would be a topic for itself. However, all in all, the illustration provides a map to start the journey. Let’s walk through it.
The process starts with the creation of a purchase order by the buyer (B00) and of a corresponding Sales order at the supplier (S00). These steps are typically not reported to authorities, hence the grey boxes at G00 and G01. We also skip merchandise preparation to arrive at the creation of a transport document (S02). For government auditors, the purpose of transport documents is to facilitate tax-related controls during goods transportation. The police can stop trucks on the road and check that their loads have been properly declared (G11). To enable that cross-checking, a reference to the transporting vehicle is mandated in the electronic documents (S02 or S03). If transport is initiated by the buyer (B02), then the buyer might have to create transport registration (B02) and/or transport documents in place of the supplier (B03).
The next steps deal with the invoice itself.
A unique identifier of invoices is key to the data quality of government platforms. Therefore, they require more than the simple invoice numbering provided by accounting systems. Instead or in parallel, an Official Document Number (ODN) is expected. Here also, several approaches co-exist. A government agency can provide each business with a range or list of pre-assigned billing numbers. During billing, clerks then tip in or copy ODNs from the lists or get them assigned from a built-in sequence by their accounting package. The list itself can take several forms : e-mail, PDF, Excel, XML, Webservice, etc. A reversed approach to ODN also exists, businesses create the ODN themselves and register (or clear) it with the government platform. This is represented by the double arrows between S04 and G04. The sequence of ODNs and the possibilities to cancel documents are extra attention points as they might impact the ability to ship and bill whenever a mandatory sequence is broken. Businesses also have to report exceptions and gaps in their usage of ODNs. This can be done in specific monthly reports or in government portals.
Similarly, businesses might be required to register invoice details (S05 and G05). In some countries, the government platform even distributes the invoice to the buyer (G06 and S06). The requirements, in that case, can include the following:
- Invoice formatting (e.g. as XML),
- Signature,
- Communication,
- Need for third parties that are certified or accredited by tax authorities.
Here, it’s also important to look at the type of invoices in scope, for example:
- Business-to-government,
- Business-to-business invoices,
- Consumer invoices,
- Export and import invoices,
- Industry or goods specific invoice types (for example for oil and gas, alcohol).
Some countries consolidate invoice and transport documents to one document. Transport information is then a mandatory content of invoices and invoice copies are given to the transporter (T06) to enable road controls. Specific print forms for transport documents (S03) and/or invoices (S06) might be required. They typically include QR-codes to simplify road controls and other audits.
Archiving is the last step of the billing process (S07 and B07). Local archiving or locally certified archiving providers might be a requirement.
In countries where electronic documents are mature, like in Mexico, the payment process might be mandated too (B08, G08, and S08).
After the fact, transactions often have to be reported e.g. in VAT or sales-tax reports or via standard accounting files (aka SAF-T). In this case also, double arrows are relevant as businesses might be required to validate the reports that governments have created for them. In some other cases, governments deprecate these reports after the introduction of mandatory electronic invoicing.
As a last step along the map, the data available on the government platform is used to spot suspect transactions (G12) and trigger onsite audits (G10, G13).
These are the attention points to analyze electronic document requirements. The source for such information is typically a website operated by the local ministry of finance. In the evaluation process, your organization should involve tax experts and internal and external auditors.
The Dynamics of Change
Knowing the dynamics of change in tax laws helps predict the chain of events and plan ahead of time. Typically, governments introduce mandates in this sequence:
- ODN numbering (S04)
- Optional electronic invoicing
- First e-invoicing mandates for bigger businesses, specific industries (e.g. oil and gas) or with suppliers of state organizations (aka B2G)
- Progressive extension of the e-invoicing mandate to all businesses (S05, S06, B06)
- Mandate for transport documents (S02/03, B02/03, T02/03)
- Adjustments to reporting requirements (S09, B09)
- Mandate for payments (B08, S08)
The introduction plan might combine some phases, but the overall sequence typically remains.
Dealing with mandatory electronic documents sometimes feels like a journey without a finishing line. We hope that the above map will help along the way.
[1] Bruno Koch, Billentis, The e-invoicing journey 2019-2025, page 19.
PS: Within SAP S/4HANA Cloud implementations, the most relevant scope items for the topic under discussion in this blog post include the following:
- Procurement of direct materials (J45)
- Sell from stock (BD9)
- Credit memo processing (1EZ)
- Debit memo processing (1F1)
- Core inventory management (BMC)
- Accounting and Financial Close (J58)
- Accounts Receivable (J59)
- Accounts Payable (J60)
- SAP Managed Tags:
2 Comments
