5 mistakes in the OSS process that many people don’t know about

Guest article: Daniel Michael, countX GmbH

Header image for guest article by CountX on the topic of

Once the biggest VAT reform of recent decades, it has become an everyday routine for many companies: The OSS procedure.

The One-Stop-Shop has been with us for over two years now. Theory and practice are converging more and more, many online retailers have found solutions for handling the procedure, but for many new retailers it is still a challenge.

Excursus: The OSS procedure results in the elimination of cross-border VAT obligations due to delivery thresholds being exceeded. VAT obligations in other EU countries can now be handled “conveniently” from the country of domicile. Click here for the general definition.

Table of contents

  • There are errors and there are errors
  • #1 Deadline for reporting is the 31st of the following month
  • #2 The payment cannot be assigned
  • #3 External warehouses are not stored in the BOP
  • #4 Completion of the OSS message
  • #5 Manual processes
  • Conclusion: Know the risks, avoid errors, submit expenses

There are mistakes and there are mistakes

The OSS procedure was generally associated with a great potential for making mistakes and not fulfilling one’s VAT obligations 100% correctly. The classics of major omissions are now well known, as they usually cause quite significant damage. We are talking about:

  • Late/missed registration for the OSS procedure
  • Missed notifications (despite registration) that lead to blocking from the OSS procedure
  • Incorrect calculation of the OSS delivery threshold
  • Incorrect calculation of OSS transactions (especially Amazon FBA with external warehouses)

However, the devil is in the detail and even retailers who think they have the OSS process under control are constantly making mistakes that can have far-reaching consequences. And they do so unknowingly. In other words, mistakes that many are unaware of. 5 in number.

#1 Deadline for reporting is the 31st of the following month

This is basically correct, but this is where the first potential for error lurks. Data has to be prepared, various parties are involved and things are getting tight towards the deadline. It is not uncommon for the report to be submitted at the last minute, i.e. on the 31st. Phew, done.

What is not taken into account here is the fact that the procedure is not 100% complete with the notification. Reports can be rejected and, above all, the payment still has to be distributed by the BZSt to the individual tax offices throughout the EU. This can lead to delays in the receipt of payments, for which the deadline also applies. The consequence: late payment interest and bureaucratic expenses, despite timely notification. Our neighbor from the Netherlands in particular is very consistent here.

You should also take into account any public holidays or weekends that may fall within this period.

Tip: Report with a buffer of several days before the deadline. This gives you time to react and distribute the payment.

#2 The payment cannot be allocated

Even if the payment has been received on time, it still has to be assigned to the paying company. This is done via the cash register reference and usually only via this reference. The cash code is assigned at the start of the OSS process, you are informed of this by separate message and gives each registered company a unique selling point.

When making a payment, this cash register reference must then be entered as the reason for payment, otherwise the payment may not be assigned to the company and, in case of doubt, it will be rejected.

Tip: Always have the reference number to hand if you do not know it and always state it as the reason for payment.

#3 External warehouses are not stored in the BOP

This mainly affects Amazon FBA merchants who participate in the CE or PAN EU program and store their goods in warehouses outside their home country and sell them from there. This triggers a far greater decentralization and, conversely, the goods cross far more national borders in their sales. By definition, this is relevant for the OSS procedure.

This diversification in the countries of origin can only be reported correctly in the BOP portal if the individual locations are stored and taken into account in the report. If this is not the case, the declaration is rejected and is deemed not to have been submitted.

Tip: Enter warehouse locations from abroad in the BOP Portal. Not a tip, but a must. If you are unsure about what and where to enter something, please contact us.

#4 Completion of the OSS message

The fact that a report has been uploaded to the BOP portal and thus sent does not mean that it has been accepted. It can take up to 48 hours for you to receive confirmation of acceptance of the OSS report in your mailbox. Or even a rejection of the notification.

The nasty thing: The communication here only involves the BOP internal mailbox, which must be actively checked. It is not communicated via common email addresses, but only BOP internally. The reason for rejection is, for example, the non-consideration of external warehouses described under 3.

Tip: It is essential to check whether the notification has been accepted 48 hours after it has been submitted to the BOP. The buffer from 1 helps here again.

#5 Manual processes

Experience reports have shown that more and more retailers have developed a system to map the OSS process. In other words, they have literally developed it themselves. Data is exported from e.g. Amazon transaction reports, elaborately prepared in Excel lists, handed over to the tax consultant, who in turn manually makes the entry in the BOP.

Manual processes and the assumption of responsibility as far as the eye can see. The potential for making mistakes here is complex and depends on the attention and diligence of the person involved at several points. This should be avoided.

The solution is as simple as it sounds. There are systems and programs that calculate the OSS reports and process the data validly and automatically, regardless of the amount of data. An OSS report should never be subject to manual processes!

Tip: If there is a manual process, however well-rehearsed it may be, it is prone to errors. Look for a system that specializes in the OSS process. That way you are also free of responsibility.

Conclusion: Know the risks, avoid mistakes, pass on expenses

As already indicated above, there are mistakes and errors. Even retailers who think they have the OSS process under control can still make minor and major mistakes. Of course, many have it completely under control by now. However, there are those who find themselves in the above-mentioned points or are not exactly sure whether these points apply: Reassure yourself about the respective handling and correctness of the OSS procedure.

The problem is that sanctions are not imposed on an ongoing basis and, in cases of doubt, errors only become apparent when it is too late and action has to be taken because tax offices carry out a comprehensive audit.

Tip: You cannot register for the OSS too early, but you can register too late. It is advisable to register for the OSS procedure across the board and to use systems such as countX for processing. This massively reduces the probability of acting incorrectly or even too late.

If you have any questions about the above points, please contact countX at any time: hello@countx.com or call +49 30 62 93 15 599.


Read also:
What is the One-Stop-Shop (OSS)? (german Help Center)
Free onboarding webinars in the easybill service package
Tax changes in 2024