Sometimes you pay Reverse Charge in D365

Sometimes you pay Reverse Charge in D365

Under the “reverse charge system” it is the company receiving the service that is liable to pay the VAT, and not the company providing the service. Normally, the net amount of VAT to pay is offset by the same amount of the receivable VAT, and the tax burden remains 0. But not always: sometimes the tax office wins. These are 2 common cases:

    • A service was provided by an EU entrepreneur who had no EU VAT number. The invoice was VAT excluded, but I had to calculate the VAT payable (reporting code 1157 „Steuerschuldübergang bei Bezug gemäß § 19 Abs. 1 zweiter Satz, § 19 Abs. 1c“ in Austria, code 47 „Steuer, im Inland steuerpflichtige sonstige Leistung eines EU Unternehmers § 13b Abs. 1 UStG“ in Germany), while the VAT receivable was nil (otherwise reported as 1166 „Vorsteuer: Steuerschuldübergang gemäß §19, grenzüberschreitende Leistungen“ in Austria or code 67 „Vorsteuer aus Umsätzen nach §13b Abs. 2 Nr. 11“ in Germany).
    • In the case of the self-billing (Gutschriftverfahren) a foreign agency may pay money to an entrepreneur by issuing an invoice on her/his behalf. If the entrepreneur does not have a VAT registration, or it is a small business, the VAT receivable cannot be recognised and the entrepreneur becomes liable for tax. If you register the agency as a customer it is a no-brainer, but the problem is in the non-continuous invoice number issued by the agency.

Solution in Dynamics 365 for Finance

The common business process distils into 3 steps:
– One receives an invoice (or a self-billed credit note) from a supplier (vendor) over €100
– One pays €100 to the supplier (or becomes €100 from the supplier)
– One pays €20 (or €19 in Germany) to the tax office
 
To implement this in Dynamics 365 for Finance, we activate the Use tax in the VAT group (en-us: Sales tax group) as usual (see Minimalistic EU VAT configuration in D365):

On top of that, the special VAT code (here: ServEUnond) for the non-deductible Reverse Charge receives Non deductible % = 100% in the tax code value:
 
The use tax VAT from the supplier invoice calculated in this way “elongates” the original expense, the GL voucher reflects the fact that the service effectively becomes more expensive by 19% (in DE).
This may be considered right or wrong, but a different expense account such as 7xxx “VAT, non-deductible” is not possible in standard Dynamics 365. If needed, this tax expense may be reallocated to a different account manually at the end of the period.

The monthly/quarterly Tax > Declaration > VAT > Settle and post VAT operation does not find any VAT receivable to offset the VAT payable and transfers the liability into the Tax authority’s payable account:
Bingo!

In the case of self-billing, the VAT payable is subtracted from the revenue: the credit note is booked as a revenue via a specially prepared procurement category, for example. The VAT “contracts” the revenue, and in order to do so, the rate of the tax must be negative (!), i.e. -20% (or -19% in Germany). The Negative VAT percentage must be activated first at the tax code record. 

Minimalistic EU VAT Configuration in Dynamics 365

Minimalistic EU VAT Configuration in Dynamics 365

Introduction

Let me present my 4th iteration of the EU VAT setup in Dynamics. The below concise VAT configuration in Dynamics 365 for Finance has been tested over 3 years of my operations. It has been constantly updated with the changes in taxation. It covers intra-community import, export and import of services within the European Union and beyond, domestic supplies, business travel within the EU and abroad.

Before we begin with the setup let me explain some background facts and assumptions:

    • Any export of goods or services in or outside of the European Community is tax-free, but reported
    • An export of services is special: in accordance with Directive 2008/8/EC any service rendered for customers abroad is subject to reverse charge
    • In the case of an intra-community (IC) delivery, goods and services are presented separately on the EU Sales List
    • On the contrary, goods and services delivered in the home country are reported together and should not be distinguished
    • Intra-community deliveries are reported separately from the foreign trade with the so-called 3rd countries (i.e. countries which are not the 28 members of the EU, e.g. Norway or Switzerland). IC trade appears of the EU Sales list, while 3rd country trade does not. Deliveries of tangible goods are reported to the INTRASTAT in addition.
    • Most of the countries apply a full rate and several reduced rates. The reduced rates are there mostly for the basic consumer services and goods (Austria: 10%). They normally do not affect enterprises, until the employees start reporting travel expenses.
    • A semi-reduced “hotel” rate of 13% stands out in Austria, but also in Switzerland and France for accommodation. Update 2018: 13% were reverted back to 10% in Austria, but I am going to keep it in my scheme.
    • A grocery may have separate tax codes for an IC acquisition of Polish potatoes (self-assessed 10%) or French wines (self-assessed 13%). However, the reduced-% goods and services are rarely imported by manufacturing or professional service businesses, with the exception of foreign books and printed media (self-assessed 10%).
    • In Switzerland, the VAT receivable from investments is reported separately from the VAT received from current assets or services (de-ch: “Vorsteuer auf Investitionen und übrigem Betriebsaufwand” vs “Vorsteuer auf Material- und Dienstleistungsaufwand“) despite the same rate.
      Since 2019, a similar aspect has become valid in Austria too. The mandatory Chamber of Commerce contribution (de-at: “Kammerumlage 1” or KU1) is evaluated at 0,29% of the total VAT receivable excluding any investments i.e. assets acquired either domestically or abroad.
      The reduced VAT (foodstuffs, pharmaceuticals) may be neglected: milk is unlikely to become a long-term asset, unless condensed 😉
    • From the system point of view, there is a difference between a “zero rate” and “no rate”. A tax code with a 0,00 rate still logs the tax base for reporting, as long as a record in the tax Values table exists.
      From the fiscal standpoint, there is a difference between a “zero” an “no” rate too. For example, in the UK public transportation is taxable at 0% which is considered a tax rate of its own. In France, 0% is applied to newspapers. To enable a zero rate, just open the Values table in connection with the tax code, let the system create a record, leave the Value = 0,00000 and save the record.

VAT codes (en-us: Sales tax codes)

Tax code Name Rate AT Example
doF Domestic VAT, full 20% Sales or purchase of regular goods and services, e.g. raw materials, office consumables, car expenses (electric cars or ‘fiscal trucks’ only)
doA Domestic VAT from assets, full 20% Investments in long-term assets, i.e. machines, office equipment, electric car fleet
doH Reduced “hotel” rate 10% This reduced rate applies to accommodation, but not restaurant bills
doR Domestic VAT, reduced 10% Public transportation, taxi, and basic foodstuffs, including restaurant bills with non-alcoholic beverages, books and newspapers; in Germany it is slightly different: dishes served in a restaurant are charged with the full tax rate, while the ‘take away’ foodstuff is reduced
TF Tax free
Out of scope
0% Exempt international air and sea transportation, or services delivered by “non-genuine” tax exempt suppliers such as insurances, postal services (de-at: “unechte Steuerbefreiung“), but also the City tax (de-at: “Tourismusabgabe“, “Ortstaxe“) component on hotel bills. The base on purchases may still be reported to the authorities.
NR Not recoverable On a travel abroad, services consumed by the employee are taxable per se, and within the European Community the tax may even be recovered, but very few companies do so. The code is not reported to the authorities. Running expenses from traditional personal cars with internal combustion engines fall into this category too.
euF IC export
IC acquisition
0%
20%
Delivery of goods to another country of the European Community is tax free, but the value of the goods is reported to the tax authority.
On a regular import of goods from another member of the European Community the full domestic tax is levied; the tax is self-assessed with a zero effective tax load (what you pay is what you get recovered). This is achieved with the Use tax (en-us) i.e. Import VAT / purchase VAT (en-gb) setting in the VAT group.
euA IC asset export
IC asset acq.
0%
20%
It is highly likely, that the investments into long-term assets (machinery, other equipment) flow into another EU country. Less probably but also possible, is that used assets are sold to an EU neighbour.
euR Reduced IC export
IC acquisition
0%
10%
Delivery of goods to another country of the European Community is tax free, but the value of the goods is reported to the tax authority.
On goods that would be subject to the reduced tax rate domestically (e.g. books), the same reduced tax rate is applied when procuring such goods from another member of the EU; the tax is self-assessed with a zero effective tax load and the Use tax setting in the VAT group.
euS IC services export
IC services import
0%
20%
Delivery of services in another country of the European Community is tax free but reported.
The buyer, however, must obey the reverse charge principle. The setup for the reverse charge and the zero tax impact is similar to the above IC goods acquisition.
exF Export 3rd county
Import 3rd country
0%
~20%
The export of goods is tax free in most of the countries, but the value has to be reported.
Tangible goods imported into the EU from a 3rd country is subject to an import tax, whose base is hard to calculate because it includes the portion of insurance and freight up until the border. Normally the import tax is calculated and paid by the customs broker; in the exotic import tax self-assessment mode (de-at: “Einfuhrumsatzsteuer geschuldet”) this exF tax code may be used to post the tax.
exS Services export 3rd
Services import 3rd
0%
20%
If the place of supply of services is outside of the EC, the export is tax-free but still have to be reported (as taxable elsewhere under the reverse charge regime).
The procurement of services outside of the EC is subject to a self-assessed reverse charge.

VAT groups (en-us: Sales tax groups)

In every business case in Dynamics 365 for Finance, the tax code is deducted by the system from an intersection between the customer/supplier VAT group and the product Item VAT group. Aside of the basic “F”, “S”, “TF” item VAT groups I recommend “H”, “Food” and “PubT” for the travel expense recording. The reason to separate the latter 2 groups is my reverence to companies holding multiple VAT identification numbers (UIDs) in different EU countries: tax rates for these categories vary across Europe.

It is a good practice to have a valid tax code, i.e. a valid Customer/Item group combination in every business case whenever it is present on the tax declaration or not. This is enforced by the tax parameter Check tax code. For example, on a business trip from Germany to Hungary the VAT may theoretically be recovered, but hardly any company does it. One way is omit the tax completely, but to stay compliant to the Check tax code setting, the tax code NR has been introduced. The respective VAT group AP-NR may be then assigned to the country HUN in the Travel and Expense module, and any foreign Hungarian VAT will be neglected yet formally recorded on the tax code NR.

Any business case we do not anticipate or consider a human mistake is going to result in a missing VAT code, e.g. an attempt to sell milk by a consulting company, or a foreign trade operation in a society without an EORI number. With the strong Check tax code setting such an attempt is going to result in an error and roll the transaction back, preventing havoc in the ledgers.

Customer or supplier VAT group Item VAT group “F” (full) Item VAT group “A” (assets) Item VAT group “S“ (services) Item VAT group “TF“ (tax free) Item VAT group “H” (hotel) Item VAT group “Food“ Item VAT group “PubT“ (public transp.)
Suppliers
AP-DO doF doA doF TF* doH doR doR
AP-EU euF** euA euS TF NR euR NR
AP-EX exF   exS TF NR NR NR
AP-NR NR NR NR NR NR NR NR
Customers
AR-DO doF doA doF TF      
AR-EU euF euA euS TF      
AR-EX exF   exS TF      

*) Tax codes to be marked Exempt in the VAT group configuration are stroke through,

**) and those marked as a Use tax are in italic.

Disclaimer

The above configuration is going to work well in the D-A-CH countries, in Scandinavia and even in Spain. Yet it doesn’t account for the “VAT on payment” aka Conditional tax common in France (de: “IST-Besteuerung“), and it will probably not work for countries with inflated reporting requirements (Italy). The Conditional tax may however become highly relevant if the customer is required to pay a significant advance payment. That case is treated in the blog Advance payment invoices in Fixed fee projects in D365, D-A-CH style.

Input validation and messaging in the Process Guide Framework

Input validation and messaging in the Process Guide Framework

A few words of introduction: Process Guide framework is THE framework for new Warehouse management mobile screens and menu items in “Dynamics 365 Supply Chain Management”:
…/warehousing/process-guide-framework

I find that the topic of the validation of data entered or scanned by the user is very superficially covered. When you read the above shallow documentation you may think the ProcessGuideStep.isComplete() method is a good place to give an error, but it is NOT. It would be too late: by the time the execution reaches isComplete() the user input has already been processed, accepted and serialized in the session state aka “pass” WHSRFPassthrough.

I figured out that the true validation may be programmed at 2 places: in the process() method of a class derived from the WHSControl or in the ProcessGuideStep.validateControls() method. The 2 ways require slightly different techniques and have distinct flavours:

WHSControl.process()

Inheriting the WHSControl class offers an object-oriented alternative to extending the WHSRFControlData class (this spaghetti code has been recently refactored and moved to WHSRFControlData.processLegacyControl). This technique is briefly described in the blog …/mfp/posts/extending-whs-adding-a-new-control-type .
There are pros and cons. The class is going to be used across the whole warehouse mobile app whenever you add a control with this name. This can be both good and bad:

  • The major disadvantage is that the WHSControl.process() is not triggered if the user has not entered anything into the field on the mobile device. E.g. one cannot check for an empty value, and this may lead to the “xxx is not found in the map” error message if one does not check existence of a parameter before fetching it from the “pass” WHSRFPassthrough.
  • The same validation logic is used everywhere. The code re-use is innate. This can be however too rough; for example, the below code snippet was written because the standard logic of the ProdID control was too broad: it was populating the item number and validating if it had a BOM.
  • The control is not fully aware of the context. It cannot reach the current Process Guide step object and call the Process Guide controller object back.
  • It is not fully aware of the surrounding controls either: the controls placed on the page after the current one have left no trace yet.
  • The control class can leverage the WHSRControlData instance with all its perks and shortcuts.

In WHSControl.process() you take the user entry from the parmData() and return a false result with the this.fail() method:
#WHSRF [WhsControlFactory(#ProdIdLabel)]
public class WHSControlProdId extends WhsControl
{
public boolean process()
{
boolean ok = super();
ProdId prodId = this.parmData();
fieldValues.insert(ProcessGuideDataTypeNames::ProdId, prodId);
if (! ProdTable::exist(prodId))
{
ok = this.fail("@WAX1162"); // The production or batch order number is not valid
}
return ok;
}
}

Note that you have to care about parsing the entry and storing it in the fieldValues container. On an error, the processing stops, the page reloads and the error message(s) is shown:
WHS warning

ProcessGuideStep.validateControls()

The validation in the ProcessGuideStep class has a different quality:

  • One can check for empty (mandatory) data.
  • The logic can only be re-used in a menu item made in the Process Guide framework. Such menu items are too few. You re-use the logic by adding the whole step = screen to the process flow.
  • The step has a full access to the process controller and to the preceding step results.
  • All controls are validated at once and can be checked for mutual consistency.
  • The WHSRControlData instance with all its useful methods has already been disposed of by the time execution reaches the validateControls() method. You have to write most of the business logic from scratch.

The validateControls() method is executed before the fieldValues container is merged with the “pass” container (WHSRFPassthrough) and becomes available to the mobile application. This is why you take the user entry safely from the processingResult.fieldValues structure. If you encounter an error, you throw a warning:
[ProcessGuideStepName(classStr(ProcessGuideItemConsumpPromptQtyStep))]
class ProcessGuideItemConsumpPromptQtyStep extends ProcessGuideStep
{
protected void validateControls()
{
WhsrfPassthrough pass = controller.parmSessionState().parmPass();
super();
qty = processingResult.fieldValues.lookup(ProcessGuideDataTypeNames::Qty);
if (qty * pass.parmQty() < 0)
{
throw warning("@SYS25506"); // Quantity may not change sign
}
}
protected ProcessGuidePageBuilderName pageBuilderName()
{
return classStr(ProcessGuideItemConsumpPromptQtyPageBuilder);
}
}

The warning thrown interrupts the flow, re-loads the page and presents the warning.

Success message

A related topic is an ability to present a success message to the user at the end of the process execution. You do it at the end of the doExecute() method in the process guide step:
protected void doExecute()
{
super();
// do the work
this.addProcessCompletionMessage();
}

This implementation is very limited, however: it cannot uptake a custom message and always shows the same text “Work Completed”.

The below snippet is smarter:
ProcessGuideMessageData messageData = ProcessGuideMessageData::construct();
messageData.message = strFmt("@SYS24802", journalId); // Journal cannot be posted because it contains errors.
messageData.level = WHSRFColorText::Warning;
navigationParametersFrom = navigationParametersFrom ? navigationParametersFrom : ProcessGuideNavigationParameters::construct();
navigationParametersFrom.messageData = messageData;

Unrelated conclusion: use the process guide framework and say goodbye to the WHSWorkExecute mess! 🙂