F.A.Q.
Short answers to the questions that actually come up in Italian localization projects.
Choose a topic
In most cases yes, at least as far as legal references are concerned. Legislative Decree No. 10 of 19 January 2026, the new Italian VAT Consolidated Act (Testo unico IVA), brings Italian VAT rules together in a single text, with application expected from 1 January 2027. The same legal case will therefore have a different reference article.
In D365 Finance the change mainly affects exemption and non-taxable sales tax codes: code descriptions, the texts printed on invoices, the legal reference in the Italian e-invoice and the VAT registers.
The system work starts with an inventory of where references appear and a mapping from the old article to the new one. Interpreting individual cases is up to the tax advisor, who validates the mapping before go-live.
It depends on how much the readability of historical data matters.
Updating existing codes is the faster route: descriptions and references change and, from the switch-over date, new transactions carry the new article. The risk is that documents and reprints from earlier periods show references different from those in force when the transaction was posted.
Creating new codes valid from 1 January 2027, while keeping the old ones for history, takes a few more days of configuration and testing. In return, each period stays readable with the correct references, and audits become simpler.
Either way, the mapping between old and new articles should be validated by the tax advisor before go-live.
Avoiding gaps in Italian VAT register numbering in Dynamics 365 Finance requires two safeguards: continuous number sequences wherever numbering without gaps is required, and the correct number sequence group on every customer, vendor and order. According to Microsoft’s documentation on number sequences, a continuous number sequence does not skip numbers, whereas a non-continuous sequence may; Microsoft recommends continuous sequences only where there is a regulatory requirement.
Gaps usually come from interrupted postings, cancelled documents or a missing number sequence group, which makes the system fall back on a default sequence. For continuous sequences, Dynamics 365 Finance provides a clean-up process that recovers numbers left pending after an error.
In practice, avoid default sequences that could be used for tax documents, schedule the clean-up during off-peak hours and re-check the VAT registers after every version update.
In Dynamics 365 Finance the VAT credit from the previous period is entered in the Previous sales tax credit (-) field of the Sales tax payment section, when the Italian VAT settlement printout is generated. If the field is left blank, the credit is not included in the balance shown on the printout.
The Sales tax payment section also contains the Sales tax credit for compensation (-), Previous sales tax debit (+) and Sales tax paid in advance (-) fields, which feed into the Sales tax balance field according to the Microsoft documentation on the Italian sales tax summary report.
In practice, first have the credit amount confirmed by whoever is responsible for tax compliance, then enter it in the period they indicate, and finally check in every later period that the value is consistent with the ledger balance. Any later adjustment to these fields needs the same authorisation.
In Dynamics 365 Finance a posted invoice with the wrong Italian VAT is not edited: the usual approach is a credit note that reverses the original invoice and a new invoice with the correct sales tax code. The choice of document and period should be approved by whoever is responsible for tax compliance.
Dynamics 365 Finance provides the Credit invoicing function, enabled with the Credit invoicing option on the Updates tab of the Accounts receivable and Accounts payable parameters, as described in the Microsoft documentation on credit invoicing for Italy. Once a sales tax settlement period is closed, Dynamics 365 Finance allows no changes to it.
In practice, first have the correction confirmed by the tax adviser, then post the credit note, and finally issue the new invoice. A duplicate sales tax code created only for the correction is not recommended, unless there is a specific tax or technical need.
If the corrected invoice is blocked because of its date, see Why does Dynamics 365 Finance block an Italian invoice dated earlier than the last one in the VAT book section?.
In Dynamics 365 Finance, the VAT-free ceiling (plafond) used by a customer’s Italian intent letter is checked with the Posted sales tax function on the letter, which shows the related sales tax transactions. The sum of the taxable amounts of those transactions gives the amount already used.
The figure is reliable only if every invoice is linked to the intent letter. An invoice posted with the right sales tax group but without a reference to the letter is left out of the total. For this reason, the Usual exporter option on the customer and the assignment of the letter at invoicing are the basis of the check.
The company’s own plafond, when the company itself is the usual exporter towards its vendors, is tracked instead with the Tax plafond feature and its Plafond transactions. The customer-side functions are described on the Microsoft page on intent letters.
In Dynamics 365 Finance, importing Electronic Reporting configurations from the Dataverse repository requires one of these security roles: Electronic reporting developer, Electronic reporting functional consultant or System administrator. Dataverse also needs a security role with permissions on specific tables.
Microsoft’s documentation on importing ER configurations from Dataverse lists the Create, Read, Write, Delete, Append, Append to, Assign and Share permissions, at Organization scope, on four tables: Electronic Reporting Configuration File, Electronic Reporting Configurations Index File, Globalization Feature File and Globalization Features Index File.
In practice, these roles are best assigned before any intervention is needed, for example to whoever supports the Italian localisation, rather than requested when an Italian e-invoice is already in error.
To set up access for an external localisation consultant, see How should a group give its external Italian localisation consultant access to Dynamics 365 Finance?.
No, Italian law does not require it: since 2013 an invoice must carry a progressive number that identifies it uniquely, not a number that restarts every calendar year. The Italian Revenue Agency (Agenzia delle Entrate) confirms this in its reply to ruling request No. 505 of 29 October 2020, which refers to Article 21(2)(b) of Presidential Decree No. 633/1972 (DPR 633/1972) and to Resolution No. 1/E of 2013.
Companies may therefore continue their existing sequence or restart from 1 each year, provided that every invoice remains unambiguously identifiable, for example by including the year in the number.
In Dynamics 365 Finance this choice is implemented through number sequences: to restart each year, use separate yearly sequences linked to number sequence groups, or a scope that combines legal entity and fiscal calendar period, as described in Microsoft’s documentation on number sequences. The decision should be agreed with whoever handles tax matters.
Yes, within clear limits. In Dynamics 365 Finance, a user with the project owner role in Lifecycle Services can pause a service update, but only one consecutive update at a time. The delay is not indefinite: at least two updates a year must be taken.
According to Microsoft’s documentation on pausing service updates, an additional pause is granted only for a confirmed Microsoft product bug or regression with no viable workaround. An open support request on its own is not enough. Issues in customisations or third-party solutions do not qualify for additional pauses.
Postponing the update makes sense when the regression affects tax processes, such as the numbering of Italian VAT registers or e-invoicing. In the meantime, it is worth opening a ticket with Microsoft, tracking the fix and repeating the tests in a sandbox before updating production.
To plan the tests after an update, see What should you test after a Dynamics 365 Finance update with the Italian localisation?.
After a Dynamics 365 Finance update, companies using the Italian localisation should test at least the tax processes: Italian VAT register numbering, e-invoicing, VAT settlement, statutory printouts and Electronic Reporting reports. Testing takes place in a sandbox, before the update reaches production.
In the automatic service update cycle, the sandbox is updated seven days before production. A written list of key processes, with an owner for each one, makes those seven days usable.
In practice, first post invoices from journals and from orders and check the numbering. Then generate test e-invoices and inspect the file. Finally, run the VAT settlement and the printouts. Tax features in preview should be enabled only after thorough testing, because in Feature management some features cannot be turned off once enabled.
If a test reveals a regression, see Can you pause a Dynamics 365 Finance service update that introduces a regression?.
In Dynamics 365 Finance, an external consultant supporting the Italian localisation should get access through a dedicated security role defined in advance, not through permissions added at the last minute. The role holds only the duties needed and is enabled for planned support windows.
Role-based security in Dynamics 365 Finance never grants access to individual users, only to security roles; a user without a role has no privileges. Administrators can create new roles or modify the sample roles provided by Microsoft.
In practice, first agree the scope of the role with the consultant and central IT. Then decide who enables and disables the account, and within what response time. Finally, check access before Italian tax deadlines, not during them.
To choose the Electronic Reporting roles to assign, see Which security roles are needed for Electronic Reporting in Dynamics 365 Finance?.
Dynamics 365 Finance blocks posting of an invoice dated earlier than the last invoice posted in the same Italian sales tax book section (sezionale IVA) when unified posting date control is enabled. The control protects the sequential, gap-free numbering of the sales tax book section.
According to the Microsoft documentation on Italian sales tax books, the (Italy) Unified posting date control feature adds a Skip posting date control column to the Italian sales tax book sections page: with the checkbox cleared, the default setting, the block applies. Dynamics 365 Finance also prevents posting or reversing an invoice dated before the closing date of the tax period.
Possible technical solutions, such as a new sales tax book section or posting in the following period, affect the VAT books and the VAT settlement, so the choice should be approved by whoever is responsible for tax compliance before it is configured.
If the invoice needs correcting after posting, see How do you correct a posted invoice with the wrong Italian VAT in Dynamics 365 Finance?. For another numbering-related block, see Why does Dynamics 365 Finance block an invoice with a continuous number sequence error?.
Dynamics 365 Finance blocks an invoice with a continuous number sequence error when the number to be assigned is out of step with the state of the sequence. Typical causes are a number left pending after an interrupted posting, or a next number changed manually.
According to Microsoft’s number sequences documentation, a continuous number sequence does not skip numbers: if a transaction is cancelled, the number is recycled. The cleanup process, run manually or as a batch job, recovers numbers lost after an unexpected failure.
To fix the error, work in order. First, check the invoice journal for the last number posted; then compare it with the pending numbers and the next number on the sequence; finally, run the number sequence cleanup. If an invoice number has genuinely been lost, agree the correction with whoever handles Italian VAT compliance.
If the block concerns the invoice date instead, see Why does Dynamics 365 Finance block an Italian invoice dated earlier than the last one in the VAT book section?. In order to change the next number sequence value it is suggested to involve a D365 F&O expert.
Yes, in Dynamics 365 Finance the next number of a continuous number sequence can be changed. For Italian invoices, though, do it only after checking the last number posted: moving it forward creates a gap, moving it back restarts from numbers already assigned.
Italian law requires each invoice to carry a progressive number that identifies it uniquely (Article 21(2)(b) of Presidential Decree No. 633 of 1972, the Italian VAT Decree), as the Italian Revenue Agency (Agenzia delle Entrate) recalls in its ruling No. 505 of 2020. This is why Italian invoices usually run on continuous sequences, which Microsoft’s number sequences documentation recommends only where there is a regulatory requirement.
Before changing the next number, check the invoice journal for the last number posted and run the continuous sequence cleanup, which recovers pending numbers. Any manual change to Italian invoice numbering should then be agreed with whoever handles Italian VAT compliance.
If posting stops with a sequence error, see Why does Dynamics 365 Finance block an invoice with a continuous number sequence error?.
In Dynamics 365 Finance, Italian withholding tax (ritenuta d’acconto) on professional fees does not appear on the posted vendor invoice because the system calculates it at payment. The withholding tax is calculated in the vendor payment journal, deducted from the payment and posted to the withholding tax account.
This behaviour is consistent with Article 25 of Presidential Decree No. 600 of 29 September 1973, which links withholding tax on self-employment income to the moment of payment.
To see an amount on the invoice, from version 10.0.33 Dynamics 365 Finance offers the Estimate withholding tax amount on invoice option in General ledger parameters, which shows an estimate on purchase orders and vendor invoices. The final withholding tax is still the amount calculated at payment, as described in the Microsoft documentation on withholding tax in purchase transactions.
In Dynamics 365 Finance, opening balances are imported with the General journal entity in Data management, which accepts lines with the Ledger, Customer, Vendor or Bank account type. A single journal can therefore load ledger balances as well as open customer and vendor items.
According to Microsoft documentation, the General journal entity used with the data management framework performs only minimal validation during import: reversed signs or wrong accounts reach the journal without being blocked.
First, master data is loaded and checked; next, the journal is imported into a test environment, using the import job history to review processed and failed records; finally, sub-ledger totals are compared with summary account balances before posting in production.
It is suggested to involve a D365 F&O data migration specialist for data migrations activities.
Utilizziamo solo cookie tecnici necessari al funzionamento del sito. Non svolgiamo attività di profilazione, marketing o tracciamento pubblicitario. Maggiori dettagli sono disponibili nella Privacy Policy e nella Cookie Policy.
© 2026 Eduardo Belli – Privacy Policy – Tutti i diritti riservati.
