Nicola Cenderelli Finance Consultan

In the vendor account statement, all types of transactions recorded for the vendors are included. However, not all of this information is necessary. Most of the time, it is superfluous information that makes it harder to understand the content of the account statement.

The system generates settlement transactions to reconcile the financial dimensions when the financial dimensions on the credit entry differ from those on the debit entry with which the settlement is made.

Let’s assume this scenario:

1. Credit transaction with financial dimensions 1-2-3 and an amount of -1,000.00
2. Debit transaction with financial dimensions 1-2-3-4 and an amount of 1,000.00

If the user settles these transactions, the system generates the following settlement transactions:

1-2-3 1,000.00 debit

1-2-3-4 -1,000.00 credit

This is useful for balancing the financial dimensions set, but these transactions should not be included in the vendor statement because they do not relate to invoices, payments, or purchase orders.

Currently, the "Financial Tags" functionality does not correctly handle "SalesTax" lines in invoice journals where there are general ledger lines associated with item sales tax groups linked to non-deductible sales tax codes.

When the journal contains multiple lines with item sales tax groups related to non-deductible sales tax codes, the system correctly splits these VAT lines into:

• Deductible sales tax lines: The account associated is the one linked to the posting profile.
• Non-deductible sales tax lines: The account associated is the one related to the original cost line.

The problem is that for the non-deductible sales tax lines that are posted to the same account as the original cost line, the financial tag information is assigned randomly by the system, choosing one of the financial tags and assigning the same tag to all lines.

Example:

Let's assume that only the cost center financial dimension is required (CC1/CC2).

Item sales tax group 22ND50 means that 50% is not deductible.

AMOUNT ITEM SALE TAX GROUP FIN TAG LEDGERDIMENSION

VENDOR 2000 F000001

GENERALLEDGER 1000 22ND50 X 4000001-CC1

GENERAL LEDGER 1000 22ND50 Y 4000001-CC2

In this case the voucher will be:

                        AMOUNT FIN TAG

F000001 2440

4000001-CC1 1000 X

4000001-CC1 110 X (THIS IS THE NON DEDUCTIBLE TAX LINE)

2000001-CC1 110 X (THIS IS THE SALES TAX LINE)

4000001-CC2 1000 Y

4000001-CC2 110 X (THIS IS THE NON DEDUCTIBLE TAX LINE)

2000002-CC2 110 X (THIS IS THE NON DEDUCTIBLE TAX LINE)

That's not correct because If I want to analyse the balance of FIN TAG "X" it will be wrong and also for the FIN TAG "Y".

The correct voucher must be:

                        AMOUNT FIN TAG

F000001 2440

4000001-CC1 1000 X

4000001-CC1 110 X (THIS IS THE NON DEDUCTIBLE TAX LINE)

2000001-CC1 110 X (THIS IS THE SALES TAX LINE)

4000001-CC2 1000 Y

4000001-CC2 110 Y (THIS IS THE NON DEDUCTIBLE TAX LINE)

2000002-CC2 110 Y (THIS IS THE NON DEDUCTIBLE TAX LINE)

In this case as you can see the correct FIN TAG is correctly splitted in the correct sales tax lines.

Currently, in Dynamics 365 Finance and Operations, when the "Date of VAT register" feature is enabled, the "Date of VAT register" field cannot be made mandatory. This is due to an existing feature that allows users to enter the date even after the invoice has been posted, if the field was initially left blank.

However, in many business scenarios, it is crucial that the Date of VAT register is entered at the time of invoice posting to ensure accounting and tax accuracy, and to avoid omissions or errors later on.

My proposal is to introduce a configuration parameter (e.g., at the legal entity or ledger parameter level) that allows organizations to enforce the "VAT Book Date" field as mandatory during invoice posting, preventing the posting process if the field is empty.

This is especially important because the Date of VAT register becomes a mandatory field for the VAT settlement and posting process. Ensuring that this field is populated at the time of posting would prevent issues with missing data and reduce the need for mass updates or corrections to posted invoices.