Question about tax-exempt intra-Community supply

[Martin Schönbeck]

Hi,

within the european community b2b sales from country to country are exempted from sales taxes. But they have to be kept asside for statistical recording. How do you do it in iDempiere?

Regards,

Martin

[reua...@gmail.com]

Hallo Martin,

That is exacltly what I was about to ask. I have to implement the reverse charge process for intercommunity trade and need some help with the implementation.
I need to add that these sales are not actually tax exempt under all circumstances. The difference to the normal VAT taxation process ist that while normally the seller ows VAT under the reverse charge taxation the buyer is charged the VAT instead.
Since the buyer in a B2B sale can reclaim the VAT from his countries tax authorities the transaction is usually net tax exempt. (Still the buyer owe the tax and probably has to pay it before it can be reclaimed)

This is actually a not so difficult idea. It can however get quite nasty if not implemented correctly.
The invoice has to strictly comply with a number of rules. If these are not properly implemented the tax authority may charge VAT tax later after a tax audit and that can get very very expensive (for the seller!!).
I can't go into much detail here because frankly I don't have the knowlegde and I do not want to give incorrect information. However there are numerous sources available. Just google reverse charge taxation.
Note: The reverse charge process can not only be applied for country to country sales and services. It can also be used within a country for a number of procduct and service categories. (trade of certain wastes and metals, building cleaning services and a couple more)

Hopefully we can get a group together to create an exhaustive and secure model implementation. You can surely count me in, since this is high on my todo list.

Andreas

[reua...@gmail.com]

I just realized the the topic has been discussed already a number of times in this group:
https://groups.google.com/g/idempiere/search?q=%22reverse%20charge%22
Hopefully we'll find a good starting point there.

Andreas

[Marco Longo]

HI Martin,

Last week we converted and tested for 8.1/8.2 and shared with an iDempiere member   our  tax extension and  vax extension.  (before they worked only on our localization fragment)

We discovered that many italian vat rules are almost the same in "all" Europe

Some things are suitable by the core like standard reverse charge. In some case or reporting you nedd FISCAL XMLreport and than you need  extra info

Why not having a first chat on Mattermost next week ?

Marco Longo

http://idempiere.consulting

[Martin Schönbeck]

Hi,

regarding the intra community supply I found, that it would suffice to have tax exempt tax entries selectable by country / country group. At the moment there is only one tax entry which is selected when having a tax exempt customer / vendor. So if you want to distinguish between intra community and extra community tax exempts you would have to assign the tax on each order line / invoice line manually. So to use this effectively the required tax entry must be selected automatically. Then all required information could be found by the invoice tax report.

AFAICS the problem discussed in https://groups.google.com/g/idempiere/c/_Xp1VF8xrpU/m/knJirwp4N9UJ is present in the actual version, so from that two taxes, e.g. DE -> DE and DE -> EU the later is selected but the more specific should be selected in my opinion. This could be resolved by allowing as target both the group and the country (DE -> EU/DE for the first one). This would be compatible for all existing systems and of course should be explained in help.

Regards,

Martin

[reua...@gmail.com]

Thanks Martin for hinting at that problem. I'll have a look at the source code and hopefully I'll be able to propose a solution after the weekend.

I still want to emphasise that it is not at all sufficient to handle the reverse charge transactions as tax exempt. At least that is the situation here in Germany but I am confident that the implementation of the relevant EU regulations is very similar in other EU countries.
To me that means we really need to model the complete process with all its features. Otherwise I think it would be very risky to use it in a real world environment since there are a number of potential pitfalls involved on both sides of the transaction.
If the seller fails to add a notice on the invoice declaring the use of the reverse charge taxation then he ows the VAT. That is also the case if the VAT number of the customer is wrong on the invoice. The seller is obliged to check the buyers VAT ID for correctness. If the buyer supplies a wrong ID the seller is still liable when that is used on the invoice. 
I may also add that also the buyer needs to be careful. Note that the buyer ows the full VAT amount for the purchased goods even in situations where only a partial refund is possible. This should also be accounted for by the iDempiere reverse charge implementation. So a full implementation of that process also has to take care of the buyer side.

Regards

Andreas

[reua...@gmail.com]

Disclaimer: Note that I am not at all a specialist in tax laws. So please take my remarks with a grain of salt. I may add however that both my bosses are attorneys specialized in commercial law. So if we should run into any problems interpreting the regulations then I know somebody who can clarify.  

Andreas

[Martin Schönbeck]

Hi Andreas,

reua...@gmail.com schrieb am Donnerstag, 14. Januar 2021 um 14:05:16 UTC+1:

Thanks Martin for hinting at that problem. I'll have a look at the source code and hopefully I'll be able to propose a solution after the weekend.

I still want to emphasise that it is not at all sufficient to handle the reverse charge transactions as tax exempt. At least that is the situation here in Germany but I am confident that the implementation of the relevant EU regulations is very similar in other EU countries.
To me that means we really need to model the complete process with all its features. Otherwise I think it would be very risky to use it in a real world environment since there are a number of potential pitfalls involved on both sides of the transaction.
If the seller fails to add a notice on the invoice declaring the use of the reverse charge taxation then he ows the VAT. That is also the case if the VAT number of the customer is wrong on the invoice. The seller is obliged to check the buyers VAT ID for correctness. If the buyer supplies a wrong ID the seller is still liable when that is used on the invoice. 

Of course it would help to have the chance to verify the VAT-ID within iDempiere. At the moment that must be done outside. But that can be handled, other than tearing apart different reasons of tax exemption.

I may also add that also the buyer needs to be careful. Note that the buyer ows the full VAT amount for the purchased goods even in situations where only a partial refund is possible. This should also be accounted for by the iDempiere reverse charge implementation. So a full implementation of that process also has to take care of the buyer side.

Do you have an example of this?

Regards,

Martin

[reua...@gmail.com]

>  But that can be handled, other than tearing apart different reasons of tax exemption.

I still think that the reverse charge process needs to be flagged as such on the seller side. Note that the invoice is only valid with the referring note and that is exclusive to the reverse charge taxation and does not apply to other reasons for tax exemption. 

> Do you have an example of this?

a) A German Kleinunternehmer receives an invoice for construction work (inland reverse charge taxation case) Then he owes the full VAT amount since the transaction is not VAT free per se. In fact the dept is reversed from the seller to the buyer (hence the name). Since he is not allowed to reclaim the "Vorsteuer" he will have to pay the amount.
b) same when a business with VAT exempt status pays their google ads. (since google sends the invoice from Luxembourg I believe)

(A Kleinunternehmer enjoys special VAT treatment under german law, other EU countries have similar exemptions)

[reua...@gmail.com]

addendum:

>  But that can be handled, other than tearing apart different reasons of tax exemption.

While I think of it: Under german tax law the vat tax empt reason has always to be declared on the invoice. So each VAT exempt reason at least has to be flagged differently to make that possible. (e.g. Reverse charge, deliveries to schools or other VAT exempt organizations.or deliveries from a Small business (with  Kleinunternehmer-Status))

[Martin Schönbeck]

Hi Andreas,

reua...@gmail.com schrieb am Donnerstag, 14. Januar 2021 um 16:10:38 UTC+1:

addendum:
>  But that can be handled, other than tearing apart different reasons of tax exemption.

While I think of it: Under german tax law the vat tax empt reason has always to be declared on the invoice. So each VAT exempt reason at least has to be flagged differently to make that possible. (e.g. Reverse charge, deliveries to schools or other VAT exempt organizations.or deliveries from a Small business (with  Kleinunternehmer-Status))

For schools you could handle it by assigning them to special customer group and evaluating this in the jasper report, if tax exempted records are present. Reverse charge (UStG 13b) is a different thing, because it depends on the project. We had this problem with a prospective customer (went away during the implementation) and we did it with a little plugin handle change events on projects and an additional flag in the project.

For Kleinunternehmer it's no real problem, because they always have to leave a message on the invoice. And even if the book the 'Vorsteuer' normally they simply don't write it into the elster formular. Those Kleinunternehmer using iDempiere.

reua...@gmail.com schrieb am Donnerstag, 14. Januar 2021 um 15:48:50 UTC+1:

>  But that can be handled, other than tearing apart different reasons of tax exemption.

I still think that the reverse charge process needs to be flagged as such on the seller side. Note that the invoice is only valid with the referring note and that is exclusive to the reverse charge taxation and does not apply to other reasons for tax exemption. 

> Do you have an example of this?

a) A German Kleinunternehmer receives an invoice for construction work (inland reverse charge taxation case) Then he owes the full VAT amount since the transaction is not VAT free per se. In fact the dept is reversed from the seller to the buyer (hence the name). Since he is not allowed to reclaim the "Vorsteuer" he will have to pay the amount.

Ok, as mentioned above it's relatively easy to avoid reclaim the "Vorsteuer". More difficult is it to correctly get the VATaccounted. But that's true for all others, too. Perhaps it can be done using a parent tax and a positive and negative rate.

 

b) same when a business with VAT exempt status pays their google ads. (since google sends the invoice from Luxembourg I believe)

AFAIK he won't have a VAT-ID, so google will charge the VAT.

Regards,

Martin

[Andreas Sumerauer]

> AFAIK he won't have a VAT-ID, so google will charge the VAT.

Not quite. Google requires the VAT ID. Otherwise they won't accept you as a customer. That is how they do their business. So even as a small business you'd have to have a VAT id (also Kleinunternehmen can get one) and pay the VAT as I have described earlier.

[Norbert Bede]

hi,

deep discussion :) not reading each details. i can share how we handle reverse charge/tax exempt, hope help if not ignore it simple in this context.

We are using parent child tax rates.  example Slovak purchase from german company. 

Tax rate mother 0% (used in document)
- child 1. + 20% Account A (used in c_invoicetax and accounting facts)
- child 2. - 20% Account B. (used in c_invoicetax and accounting facts)

we have on tax rates a field tax rate message, which include necessary texts when tax used.  (both sales/purchase) 

for loading proper tax we are using tax definition connect BP tax group, Product Tax Category, This definition has sequence and apply proper combination. Also we are able to specify tax definition rule based on country group. So if company using idempiere selling/purchasing in EU then we automatically select proper tax rate - usually this is defined for goods and services separately, if any other rule like exclude country in EU or outside eu then define this rule and load proper tax. 

Accounting and statistics is reported from child tax usage. On document you have 0 %

hope help.

norbert

[Martin Schönbeck]

Hi Norbert,

norber...@gmail.com schrieb am Freitag, 15. Januar 2021 um 16:13:04 UTC+1:

We are using parent child tax rates.  example Slovak purchase from german company. 

Tax rate mother 0% (used in document)
- child 1. + 20% Account A (used in c_invoicetax and accounting facts)
- child 2. - 20% Account B. (used in c_invoicetax and accounting facts)

That was my idea for intra eu purchases, too.

 

we have on tax rates a field tax rate message, which include necessary texts when tax used.  (both sales/purchase) 

for loading proper tax we are using tax definition connect BP tax group, Product Tax Category, This definition has sequence and apply proper combination. Also we are able to specify tax definition rule based on country group. So if company using idempiere selling/purchasing in EU then we automatically select proper tax rate - usually this is defined for goods and services separately, if any other rule like exclude country in EU or outside eu then define this rule and load proper tax.

Is the BP tax group you mentioned a field introduced by you or didn't I only find it?

Regards,

Martin

[Norbert Bede]

Hi Martin, 

i double checked, this field is deactivated, originally came from e-volution. Looks like we have activated it.

An example for a tax rate will be applied when Partner has Vat ID from EU (tax group on bp), Tax rate category from Product (eg. product can be 20% domestic, special behaviour can be used, if not required simple use fixed like EU, Domestic High Rate, or Domestic Low Rate) also country group can be used, and as result tax rate will be applied. 

I would be happy to get into the DEMO an example setup.

Behind there is a class understand these rules and apply them when BP/Product entered on lines.

Some field are our customisation on request would be interest to get into the base system.

example of parent tax +20/-20%

norbert

[reua...@gmail.com]

Thanks Norbert for the input. This looks like a feasible solution that we could use. Apart from that I am contemplating if it would make sense to introduce a sequence field to the tax rate table. the user could then control the evaluation order of the tax rates and use the first one that fits. 
like: 

1) Germany > Germany -> inland VAT
2) Germany > EU -> reverse charge (with germany included in EU country group)

3) Germany > World -> export non taxable

The world group could even include all EU countries. As long as it is evaluated last the right tax rite will be found.

On a side note: I have added a tab tax rate to the tax category window. This makes it much easier to work with the taxation setup. 
I also think that for newbies the taxation setup might be easier to understand if the dependency tax category > tax rate were made more obvious through that tab. 

regards
Andreas

norber...@gmail.com schrieb am Freitag, 15. Januar 2021 um 16:13:04 UTC+1:

[reua...@gmail.com]

> Behind there is a class understand these rules and apply them when BP/Product entered on lines.

> Some field are our customisation on request would be interest to get into the base system.

Very interesting. From the first glance it looks like also the fringe cases that I described earlier can be covered correctly.
Also thanks for your willingness to share the solution. 
I assume this is a specialized customization to implement the EU specific taxation? 

Maybe it could be tweaked to be more versatile and useful in other regions of the globe as well? (If that should be necessary)
I'd love to have a look at the source code of your class.

Thanks!

Andreas  

[Norbert Bede]

hi,

this solution able to handle most generic scenarios.   tax definition  window is for defining sequences.

one more thing. I designed, introduced concept for Tax schemas. All tax entities as tax rates, tax groups, tax categories and tax definitions is linked to tax schema, tax schema is attached to accounting schema. 

For example tenant 1 is germans - using german tax schema, tenant 2. french tax schema etc.  On document/client/org you can see only selected tax schema well.

I can collect inputs, you can help me document we can supply codes behind if necessary.

This concept is working at customers from adempiere times.

norbert

[Martin Schönbeck]

Hi Andreas,

reua...@gmail.com schrieb am Freitag, 15. Januar 2021 um 17:11:09 UTC+1:

Thanks Norbert for the input. This looks like a feasible solution that we could use. Apart from that I am contemplating if it would make sense to introduce a sequence field to the tax rate table. the user could then control the evaluation order of the tax rates and use the first one that fits. 
like: 

1) Germany > Germany -> inland VAT
2) Germany > EU -> reverse charge (with germany included in EU country group)

3) Germany > World -> export non taxable

Even better than my idea, to allow both group and country, because that wouldn't work for the 3rd entry.

 

The world group could even include all EU countries. As long as it is evaluated last the right tax rite will be found.

On a side note: I have added a tab tax rate to the tax category window. This makes it much easier to work with the taxation setup. 
I also think that for newbies the taxation setup might be easier to understand if the dependency tax category > tax rate were made more obvious through that tab. 

ACK. I don't remember how often I clicked on tax category in a product window and then remembered I had to open the tax rate directly.

Regards,

Martin

[Martin Schönbeck]

Hi Norbert,

norber...@gmail.com schrieb am Freitag, 15. Januar 2021 um 17:36:33 UTC+1:

hi,

this solution able to handle most generic scenarios.   tax definition  window is for defining sequences.

one more thing. I designed, introduced concept for Tax schemas. All tax entities as tax rates, tax groups, tax categories and tax definitions is linked to tax schema, tax schema is attached to accounting schema. 

For example tenant 1 is germans - using german tax schema, tenant 2. french tax schema etc.  On document/client/org you can see only selected tax schema well.

I can collect inputs, you can help me document we can supply codes behind if necessary.

This concept is working at customers from adempiere times.

I think, it would be great to get this into core. Of course people from outside of the EC should have a look whether there problem are attended, too.

Regards,

Martin

[Carlos Antonio Ruiz Gómez]

Sorry if this looks like a fork of the discussion but I think is relevant, about:

> Of course it would help to have the chance to verify the VAT-ID within iDempiere. At the moment that must be done outside. But that can be handled, other than tearing apart different reasons of tax exemption.

On his visit to Krefeld, Pieter explained me that he validates the VAT using this website:

https://ec.europa.eu/taxation_customs/vies/

As you can see in the technical information link

https://ec.europa.eu/taxation_customs/vies/technicalInformation.html

They provide a SOAP webservice.

I think it would be great if somebody can implement TaxID validation in iDempiere, maybe the following way:

- Add a button in Business Partner window "Validate Tax ID"

- The button must call some interface (extensible/pluggable) passing as parameter the C_BPartner_ID

- The implementation of the interface would do the necessary validations - note the validation is kind of generic in the EU, but it would be really different in other countries, so there could be multiple implementations of the interface to be called sequentially in case one of them fails - I guess the implementations need to check the format of the TaxID (for example to see if is a valid EU Tax ID to apply the validation) - other implementations maybe would require the BP Location to be filled to figure out the country (in the EU the country is part of the TaxID).

WDYT?  Is it already done?  Anyone interested?  New ticket?

Regards,

Carlos Ruiz

[Marco Longo]

Hi Carlos,

Already done :-D   we updated it last week  and should work also for 8.2.

This last version is in testing from a member of comunity.. according to him we were going to public doc & code after test.

We created a full creation of BP starting form VAT ID , We save in a VIES/VAT  Table/window and there is also a process to check if some BP are no more in the VIES

I will share a video tomorrow here or on mattermost and install on the demo so you can test. Also wiki page and code.

Note  as the information are not stored in different field (see image attached)  the plugin needs to parse the string  so we need to check it works for all countries.

Our first purpose was to create an  italian BP in just 2 second . As it works for all EU countries (or should be) we should check that it works for all countries.

As it works also from quick entry you can create a BP starting from VAT ID in the sales order wherever you want.

Marco Longo

https://idempiere.consulting

[Carlos Antonio Ruiz Gomez]

Great Marco!!

From what we saw in basic tests with VIES some countries return name and address, others return just name, and others just say the VAT is valid, but our tests were very basic, maybe could be wrong tests.

Regards,

Carlos Ruiz

El 16.01.21 a las 16:30, Marco Longo escribió:

[Marco Longo]

Hi Carlos,

you are right. we need to have (find some  real VAT IT for each EU country to test.

We could anyway create the VIES Record and save  "nodata" in the adress record  but in this way the process end succesfully and you have information about VIES 

(now the process end with an error as is not possible to retrieve the address )

Marco Longo

[reua...@gmail.com]

Hello Martin, Norbert and Marco,

Do you see any chance we get a canonical reverse charge implementation off the ground in the foreseeable future?
I would hate to reinvent the wheel . However I am afraid I would have to if we fail to get this going because this is a crucial feature that my client needs to have.

I am prepared to spend some time on the realization of the feature. So if you need any assistance please let me know.

Thanks! Looking forward to hearing from you.

Andreas

Martin Schönbeck schrieb am Dienstag, 12. Januar 2021 um 12:01:20 UTC+1:

[Norbert Bede]

Hi,

take a look the next link. 

http://www.adempiere.com/Sponsored_Development:_Libero_Global_Tax_Management

practically we are using above solution (we inherit practices from adempiere times..). Most objects are in idempiere, probably they are deactivated. 

We need support of core developers, then prepare tasks. scripts activate back fields. setup in gardenworld base scenarious. (like reverse charge)

norbert

[reua...@gmail.com]

Thanks Norbert for the link.
This looks like it can be used to model quite complex tax setups.
I have to admit though that I am not really happy with the extensive use of scripts by that solution. 
I found groovy scripts very hard and cumbersome to test and debug in comparison to java code.
That I why I would rather not trust a script with any complex and crucial business logic.

Hopefully we can use iDempieres osgi architecture to plug in specialized tax setup classes instead of the scripting that the solution uses now.

A plugin based solution would also be much easier to use for system administrators and consultants.

(I do hope for a growing library of tax implementations once the interface is provided.)

I am going to look in to the implementation and I am very interested to see how it plays with the more recent idempiere additions to the tax setup e.g. country groups.

Andreas

[Norbert Bede]

I will let you know, probably we have rewrite this to java.  (need to ask developers) n