Intrastat reporting is a legally required report for all European Union (EU) countries. It is also mandatory for all companies that have a Value Added Tax (VAT) declaration number in an EU country and a turnover over a certain threshold. (There are two thresholds: one for revenue and one for the purchasing value). All goods movements related to sales orders and purchase orders (i.e., all cross-border goods flows within the EU) must be reported in Intrastat. You can find the data used for the Intrastat reports on the foreign trade views of sales orders, sales invoices, purchase orders and purchase invoices.

EU companies must complete two Intrastat reports: one for the goods receipts and one report for dispatches. The most important data on both reports are the product’s value and weight.

In SAP ERP Central Component (SAP ECC), the creation of Intrastat reports has three steps. The first step is to manually select the data to be reported (goods flow). You can make the selection either in test mode or production mode, but the next two steps can only be executed when the selection is executed in production mode.

In the second step, you manually create an intermediate file. SAP uses the intermediate file to store the selected data in a standard format. The intermediate file may also contain transactions that you do not report to the authorities, such as cancellation documents. The intermediate file serves as the basis for the final reports that you send to the authorities.

In the third step, you manually create the file you send to the local authorities. Although Intrastat is an EU report, the format of the report for the authorities is country-specific.

The challenge users tend to experience with Intrastat reports is that the figures in the first step differ from the figures in the second step. For example, in the first step, say the value total is $1,000,000, whereas the total in the second step is $915,000. This discrepancy makes it difficult for a user to reconcile Intrastat with sales figures or tax figures, for example.

The goal of this article is not to explain all discrepancies, but to make you aware of the four reasons these inconsistencies occur:

• Data collection process
• Test run versus production run
• Cancelled sales invoices

• Legal requirements

Data Collection Process

The main cause of inconsistencies is the way SAP has to collect the data for the Intrastat reporting. This is caused by the fact that returns are to be reported on a different report. For example, sales returns should not be reported on the dispatch report, but on the receipt report. However, the sales returns are first selected by the dispatch report (the first step of the reporting process) and then selected in the second step of the receipt report.

Figure 1 shows an example of a sales invoice for a goods return. In the first step of the dispatch reporting, the sales invoice will be selected. Now when you do the receipt reporting, in the first step only purchase order-related data will be selected, but in the second step, the sales return invoices are also selected. In Figure 2, you can see that the sales return invoice is selected.

Figure 1

Sales return selected during the first step of the dispatch reporting

Figure 2

Sales return selected during the second step of the receipt reporting

Intercompany sales orders and stock transfers can complicate the process. An intercompany sales order is a sales order received by a sales organization and shipped by a different sales organization. The two sales organizations also belong to two different company codes. To select receipts/dispatches related to these intercompany business processes, use transaction VI98. This transaction also creates Intrastat data which should only be included in the second step of the Intrastat reporting.

Also, for purchase order returns, a separate report program exists: VI99. They are selected in the first step of this transaction and then reported in the second step of the dispatch reporting.

In SAP, there are four transaction codes to select Intrastat-relevant goods flows:

VE01: Select Data for Dispatch – EU Countries

MEIS: Data Selection; Arrivals – EU Countries

VI98: Select Data for receipt via SD Intercompany Billing

VI99: Returns and Credit Memos / Dispatch from MM.

For all four transaction codes, you must finalize the first step before a second step in the reporting process can start.

Test Run Versus Production Run

The first step of Intrastat reporting is to select the goods flow to be reported. Often, users first select the data in test mode in order to identify and correct errors in the reporting and compare the result of the Intrastat report with other reports, such as the VAT report. Once the information on both reports match, the production run is started, but the production run data may differ form the test run data.

For example, Figure 3 shows the result of a test selection run for the Intrastat dispatch report. Only one sales document has been selected for reporting. In this report, the tare mass (weight) is 0.150 KG. Figure 4 shows the same sales document, but after the production run. The tare mass is zero. This is standard SAP functionality. In a production run, as soon as a document is selected and there is a price correction, the fields related to weight are set to zero because the price correction has no influence on the weight, only on the value. For example, when you sell 100 kg with a value of 500 and there is a price correction of 50, you still sell 100kg, but the total value changes to 450.

Figure 3

Selection after test run

Figure 4

Selection after production run

When you execute the next step of the Intrastat report for dispatches, the document is not  selected because it is a return, causing a difference between the first step and the second step. However, this difference is caused by the standard SAP functionality that is discussed in the following section. 

Cancelled Sales Invoices

Inconsistencies caused by cancelled sales invoices are only relevant for the Intrastat dispatch report. I’ll start with an example of a cancelled sales invoice. The invoice and its cancellation are both posted in the same time period. Figure 5 shows that the invoice and its cancellation are both selected in the first step. In the second step of the Intrastat report process, both documents are not selected because they are a combination of a document and its cancellation. This is standard SAP functionality. The prerequisite for this functionality is that both documents are posted in the same period. You can find both documents in the Processes not relevant for declaration log (Figure 6). This is a standard log that shows all the documents that do not have to be reported to the authorities.  

Figure 5

The sales invoice and its cancellation in the selection log

Figure 6

The sales invoice and its cancellation are not selected for declaration in the second step

This functionality causes an inconsistency in the number of records selected. If you don’t select cancellations, the cancelled invoice will be selected in the second step (Figure 7).

Figure 7

The cancelled invoice is selected in the second step

Now it seems that if you always include the cancellations in your selection there will be no issue. Unfortunately this is not correct. When the original document and cancellation are posted in the different periods, they are treated differently than when they are posted in the same period. You will get an inconsistency when you have cancellation invoices in a different period than the original invoice. For example, the invoice in Figure 8 is a cancellation invoice with a posting date in period 3. It is related to an invoice in period 1. When you include cancellation invoices in your selection, the cancellation invoice is selected for reporting. However, in the next step, the cancellation invoice is not selected. In Figure 9 you can see that it will be shown under “Processes not relevant for declaration”. The log also shows that the original invoice is relevant for reporting in period 1.

Figure 8

The cancelled invoice is selected for reporting

igure 9

The cancellation invoices are reported as not relevant for declaration

Legal Requirements

The last cause of inconsistencies is the country-specific legal requirements, such as rounding rules for values and weight that may differ from country to country. Another example of a country-specific rule is that since 2007, the statistical values don’t have to be reported in France (as they still do in Germany, for example). Figure 10 shows the contents of the selection for the dispatch report. In the second step, the intermediate file is created. The result of this step is shown in Figure 11. In this figure, you can see that the statistical value has been deleted. It also shows that the invoice value and tare mass have been rounded.

Figure 10

Selection for dispatch reporting for France

Figure 11

Intermediate file for dispatch reporting for France - no statistical values reported

The magnifying glass in Figure 11 indicates an aggregation. In my example, it concerns a debit memo and a credit memo. These documents have the same value and have been posted in the reporting period. It is standard SAP functionality to combine invoices and related credit notes as long as they are posted in the same period.

When you compare the reporting data at the beginning of the Intrastat reporting process with the final reporting data, you may discover several differences. When you notice inconsistencies in your Intrastat reporting, you should always first check whether it is because of one of the reason mentioned in this article. If you still have doubts, you should check the SAP Notes on Intrastat, such as SAP Note 883521.

Kees van Westerop

Kees van Westerop has been working as an SAP consultant for more than 25 years. He has an MBA degree in mathematics and a degree in finance. Kees has been concentrating on the financial modules, especially in general ledger accounting, cost center accounting, and consolidation. He also has a great deal of experience with rollouts of kernel systems and integrating finance and logistics.

You may contact the author at keesvanwesterop@hotmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.