D365 BC: Mix of input and output VAT in one credit note

Once a year, I get a tricky invoice for the PV generation from my power supplier. They reimburse me for the delivery of the photovoltaic electricity into the power grid, and one invoice contains:

reverse charge (output VAT, 0%)
supplier services (input VAT, 20%)

If the energy is supplied to the grid by an entrepreneur to an entrepreneur, it is subject to VAT under the reverse charge mechanism. The reverse charge VAT is paid by the customer in this case, and the grid operator / utility company is the customer for the PV feed-in. However, usually they supply energy to our company i.e. they are registered as a vendor in the ERP system. The document is issued by the utility in my name under a self-billing arrangement (“Gutschriftsverfahren“). Consider the following:

the PV feed-in is a side revenue of my company;
one solution would be to register the vendor as a customer and perform the netting (see Consolidating customer and vendor balances in Business Central);
however, the invoice number is issued by the vendor. If the vendor is registered as a customer, the credit note can only be entered in the General journal as a generic GL transaction;
most of the revenue is VAT exempt under the reverse charge regime, but the supplier also included his services on top. These services (well hidden on the printed invoice) not only reduce the revenue, but there is also a VAT on top;
as a result, the credit note contains both the 0% output VAT (0% sales reverse charge) and the regular 20% input on services.

This was a tough case. The solution is to keep the vendor a vendor, posting revenue via a purchase document and mixing VAT directions in it.

Registering a purchase invoice did not work, D365 Business Central kept showing the “Amount must be negative in Gen. Journal Line Journal Template Name=”,Journal Batch Name=”,Line No.=’0′.“ error. Unlike Dynamics 365 for Finance, in BC the Invoice and the Credit memo are 2 distinct document types, and the invoice may not be negative. Only the Credit memo can.

Enter a Purchase Credit Memo. In one line, enter the amount received for the PV feed-in in connection with a revenue account and select a customer (!) VAT Bus. Posting Group (the group must be made visible through a personalisation). This forces Business Central to treat the VAT as output VAT despite using a purchase document.

The service shall be entered with a negative quantity against a revenue reduction account, while the VAT group remains the regular one for the input VAT:

This credit memo produces 2 VAT entries, one for the [exempt] output VAT and one for the input VAT:

The reverse charge must be reported as such on the monthly VAT statement. Unlike D365 FO, the Business Central does not strictly follow the Sales direction of the VAT when making the VAT return. In the VAT statements matrix, add the Purchase VAT into the reverse charge section to record and report the PV turnover:

This has been a good example of how Business Central’s strict document types can be worked around by combining posting logic from both purchasing and sales VAT setups. Hope this saves someone else a few hours.

Blog series on Finance and VAT in the EU

Luxembourg VAT Declaration for D365FO in PDF

There is the 2nd most prosperous country on this planet, which is apparently too small to get a proper VAT declaration in Dynamics 365 for Finance. Not too small for ER-Consult, though. We have released a complete Luxembourg VAT Declaration (TVA) built entirely with Electronic Reporting (ER) and delivered as an AED-compliant PDF form.

All relevant boxes of the declaration will be populated, including the sales regime, the key turnover fields, reverse-charge sections for both EU sales and EU purchases, the deductible VAT areas, adjustments, and all totals required for the final VAT balance, as well as the identification header. We support 17% (standard), 14% (intermediate), 8% (reduced), 3% (super-reduced) as the VAT rates, i.e. the status quo from the 1st of January 2024 onward. The title is automatically generated, based on the selected from-to date criteria.

In detail, the following sections and cells are calculated:

Section I.A: Grand total of sales A.1.b
Section I.B: Exempt sales, including “1” intra-community deliveries (457), “2” export of goods into 3rd countries (014), “3” other sales exempt everywhere (015, international transport), “4” exempt domestic sales (016, financial and insurance, postal services), “9.a” sales of goods acquired in triangular trade (018), “9.b.1” delivery of services and intangible goods into an EU country (423), “9.b.2” delivery of services and intangible goods into an EU country where they are exempt (424), and “9.c” rendering services for a non-EU customer and other operations abroad (019)
Section I.C: Total taxable sales turnover as a difference of I.A-I.B
Section II.A: Breakdown of domestic sales of goods and services (701-040)
Section II.B: Intra-community acquisitions of goods implemented as a Use tax in D365 (711-194)
Section II.D.1: Import of goods from outside of the EU for business purposes, either self-declared or recharged by the customs broker as an VAT receivable (721-195)
Section II.E.1: Receipt of reverse-charged services rendered in a foreign EU country and implemented as a Use tax (741-435)
Section II.E.2: Receipt of reverse-charged services rendered in a foreign country outside of the EU (ex: Britain, USA, India) and implemented as a Use tax (751-445)
Section II.F: Receipt of reverse-charged goods domestically in Luxembourg (for example: purchases of scrap; construction materials within the construction industry, 769-764)
Section II.H: Total of the VAT payable, aggregating all of the above
Section III.A: Totals of the VAT receivable, including “1” domestic purchases, “2” intra-community acquisitions from II.B, “3” import VAT from II.D.1, “4” reverse-charged VAT receivable offsetting the II.E.1, II.E.2 and 2.F
Section III.C: Grand total of the VAT receivable
Section IV: Grand totals and the resulting VAT load

A tax code lookup, implemented exactly like in all other supported VAT declarations in Dynamics 365 for Finance, namely under the Application specific parameters of the ER format, is fully configurable and free of hard-coding:

*This screenshot has been taken in the DEMF company of the “Contoso” demo database, hence the German rates.

All this makes the solution transparent, maintainable, and aligned with Microsoft’s Globalisation framework. The ER format is compatible with the Tax calculation add-on, too: in a multi-country, multi-VATID scenario it may be selected as the VAT declaration for the LUX country, alongside Microsoft’s standard VAT declarations for NLD or BEL.

Blog series on Finance and VAT in the EU

Troubleshoot the VAT Declaration in D365 for Finance

Users of the VAT declarations (both Excel and XML) in the financial department are often shocked by error messages of this kind:

Evaluating binding of format component Excel/Sheet1/I_Turnover/Box_200
Fehler beim Bewerten des Ausdrucks für Pfad ‚Boxes/Box81_Base‘
Fehler beim Bewerten des Ausdrucks für Pfad ‘Boxes/Box_150’.

The exact error message differs by country: the first is produced by the “VAT Declaration Excel (CH)” / “VAT Declaration XML (CH)” for Switzerland, the second one is from Germany, the 3rd is from Spain. In reality, the error has nothing to do with the “Boxes” i.e. the Excel layout but a clear sign that the Application specific parameters / Setup fail to classify a specific VAT use case. Namely, a VAT code was used in a module / situation not envisioned by the FiCo functional consultant who configured the VAT Declaration.

Update 09.06.2025: meanwhile, the recent versions of VAT declarations in Electronic reporting give an exact hint which code and tax direction fell through the grate, for example: “…(Code): „ESIN0“, … (TransactionClassifier): „Purchase“…”, and the below cumbersome algorithm of finding the date, code, and the transaction classifier became obsolete.

~~1. Use division by dichotomy to find the exact date~~

… when it happened. Most of the European VAT declarations are returned monthly, and it takes on average 7 attempts to narrow down the date. Locate the VAT declaration in the Organisation administration > Workspaces > Electronic reporting, Reporting configurations tree under the Tax declaration model node. Keep starting the report with the Run button above, variate the dates.

2. Find uncommon combinations of VAT code and Direction

Having spotted the date, filter tax transactions by that date and the VAT settlement period using the query Tax > Inquiries and reports > VAT inquiries > Posted VAT (hereafter I refer to the en-gb language of the D365 UI). Export the results into Excel. Build a pivot table by the VAT code and direction, counting the vouchers (= business cases) at the cross sections. Start looking for outliers, pay particular attention to the low counts i.e. seldom use cases. Often the mistake is obvious:

VAT code	Duty-free purchase	Duty-free sale	Use tax	VAT payable	VAT receivable
euSt	1	7	1
exSt		7
FoodR				15
R				2	5
ServSt				11
St				39

In this example, the euSt code designates VAT exempt intra-community sales, or intra-community acquisitions at the standard tax rate of 19% (= “use tax” or Import VAT / purchase VAT in en-gb, see Minimalistic EU VAT Configuration in Dynamics 365). This code is not supposed to appear in the context of a VAT free purchase, but someone managed to make such a transaction in a general ledger journal when entering a EU supplier invoice.

You cannot fix the tax transactions, but the Application specific parameters may be amended to account for this irregularity. Open this list of Conditions and filter it by the tax code in question to validate the suspicion:

You have to add a new line with this combination of the Tax code and the Transaction classifier to capture this exceptional case. Namely, a pair euSt–PurchaseExempt must be added. Try the VAT declaration one more time to confirm that the problem is now gone.

3. Use a fallback condition

Sometimes it is not that easy to spot a pattern: the occurrences may be too many even on a single day. Your next approach may be to leverage the placeholders *Not blank* for the Tax code and *Not blank* for the Transaction classifier. These lines must be placed at the very bottom of the list of conditions (note the Move down button).

Use these fallback lines with placeholders to redirect the total tax amount of the questionable nature into a separate VAT declaration cell which is typically empty, for example to the cell 61-InputTaxCorrection on the German “UVA” tax declaration. This will give you an idea how much is missing in tax, and what the tax origin amount may be.

Do not keep the placeholders in your PROD setup for long: by doing so, you are resigning and testifying that you don’t really know what is happening in the tax ledger but play dice with the tax authority, which is a very bad idea.

You may also have some tax transactions that do not need to be reported to the tax authority at all. Capture such a case with a combination of a VAT code and direction, and send it into the Other cell i.e. into oblivion:

4. If nothing helps

…then you may have encountered a true bug in the VAT declaration, a case that does not fit into any of the Transaction classifier categories but an Error one!

Indeed, recently we discovered that the reversal of a customer transaction settlement with a realised cash discount is accompanied by a positive adjustment of the VAT payable (i.e. we again own more VAT to the state, which is correct). But this adjustment is not attributed to the VAT direction of Sales, it results in an Error in the VAT declaration instead.

Add lines with the explicit Transaction classifier = Error to manage this case: