Dynamics 365 Finance 10.0.50: Customer tax numbers on sales prepayment invoices

Overview

Microsoft Dynamics 365 Finance 10.0.50, planned for December 2026, introduces a new Accounts receivable capability for sales prepayment invoices. The change addresses a situation in which the customer’s tax-exempt number or VAT registration number was not populated on the prepayment invoice.

The capability is controlled through Feature management. It should therefore be treated as an explicit functional change rather than assumed to become active immediately after the platform update.

Although this feature concerns Accounts receivable rather than payment-file generation, it is relevant to the wider prepayment process. A sales prepayment invoice is often issued before an incoming payment is received, identified, and settled. Correct customer identification on that document supports a cleaner process from invoice issuance through payment reconciliation.

What changes in version 10.0.50

With the new feature enabled, Dynamics 365 Finance is intended to populate the relevant customer tax identification on a sales prepayment invoice. Depending on the localization and customer setup, Microsoft refers to this information as a tax-exempt number or VAT registration number.

In practical terms, the expected process becomes:

1. The customer has the applicable tax registration information maintained in Dynamics 365 Finance.
2. A user creates a sales prepayment invoice.
3. The system makes the customer tax identification available to the prepayment invoice process.
4. The resulting invoice can present that identification where the applicable document design supports it.

The important distinction is that this is not described as a new tax calculation method. It is a correction to the availability or population of customer identification on a specific invoice type.

Previous pain point

Before this change, a customer could have a valid VAT registration or tax-exempt number in the master data while the sales prepayment invoice did not contain it. That difference created an avoidable inconsistency between ordinary customer invoices and prepayment documents.

The operational consequences depended on local requirements and document delivery methods. Typical issues could include:

• users manually adding tax identification outside Dynamics 365 Finance;
• invoices being corrected or reissued after customer review;
• additional checks by Accounts receivable or tax teams;
• inconsistent information across invoice types for the same customer;
• electronic documents failing a business or recipient validation rule;
• audit questions about why registered master data was not reflected on the document.

Not every jurisdiction requires the customer’s VAT number on every prepayment invoice. However, where it is required, the omission turns a routine billing step into an exception process.

The improvement removes the need to work around a system-level omission, provided that the customer master data and document format are correctly configured.

What the feature does not necessarily change

The release description is narrow. It should not be interpreted as changing all tax, prepayment, or banking behaviour.

There is no indication that the feature changes:

• prepayment percentage or amount calculation;
• sales tax determination;
• ledger posting profiles;
• customer settlement rules;
• payment references or bank reconciliation logic;
• ISO 20022 payment message content;
• the accounting treatment of a prepayment;
• tax registration validation services.

The customer tax number is also different from bank-account identifiers such as IBAN, creditor references, or structured payment references. Enabling this feature should not by itself change inbound payment matching.

Its benefit to the payment process is indirect: the prepayment invoice becomes a more complete business document before the customer initiates payment.

Behaviour that must be verified

Microsoft’s published description leaves several implementation details open. The following points should be recorded as assumptions until confirmed through testing:

Source of the registration number

Assumption to verify: the feature uses the tax registration associated with the customer or the relevant customer address. If several registrations exist, test which registration has priority and whether country, address, registration category, or validity dates influence selection.

Timing of value population

Assumption to verify: determine whether the number is copied when the prepayment invoice is created, when it is posted, or when the document is generated. This matters if master data changes between those events.

Existing prepayment invoices

Assumption to verify: previously posted documents may not be updated retrospectively. Test open, posted, cancelled, and reprinted prepayment invoices separately.

Output formats

Assumption to verify: standard reports may expose the corrected value, but custom SSRS reports, Electronic Reporting configurations, and electronic invoice integrations may require mapping changes.

Credit or cancellation documents

Assumption to verify: confirm whether related correction, cancellation, or credit documents obtain the same tax identification.

These are not reasons to delay evaluation. They define the acceptance criteria for a controlled rollout.

Who is affected

Business roles

The main affected roles are:

• Accounts receivable clerks, who create, post, send, or correct sales prepayment invoices;
• sales order administrators, where prepayment invoicing forms part of order processing;
• tax and compliance specialists, who define document requirements by jurisdiction;
• customer master-data teams, who maintain registrations and addresses;
• solution architects and functional consultants, who own the invoice design and integration landscape;
• support teams, who investigate differences between master data, posted transactions, and generated documents.

Processes

The change is relevant where an organization uses sales prepayment invoices before delivering goods or services. It is particularly important when invoices are transmitted electronically or validated automatically by customers.

Processes that do not use sales prepayment invoices are unlikely to see a direct effect.

Legal entities

Review legal entities that:

• issue sales prepayment invoices;
• operate in countries requiring supplier or customer tax identification on such documents;
• share customer records across multiple jurisdictions;
• use localized invoice layouts;
• use custom reports or Electronic Reporting configurations.

A legal entity should not be considered unaffected merely because its normal sales invoices already show the correct registration number. The defect addressed here is specific to the prepayment invoice path.

What to do before the update

1. Identify usage

Determine which legal entities and business units issue sales prepayment invoices. Collect representative examples from production, including documents where the customer tax number is currently absent.

2. Review customer master data

Check that relevant customers have complete and valid tax registration data. A system correction cannot populate a value that has not been maintained or is associated with the wrong address or registration type.

Include customers with:

• one domestic VAT registration;
• multiple registrations;
• foreign delivery or invoice addresses;
• tax-exempt status;
• expired or future-dated registrations, if used by the organization.

3. Inventory document customizations

Document all outputs used for prepayment invoices:

• standard SSRS reports;
• customized invoice reports;
• Electronic Reporting formats;
• electronic invoicing integrations;
• document-management or customer-portal copies.

Locate the field currently used for the customer tax number. The application may populate the data correctly while a customized format still omits it.

4. Define expected results

Obtain confirmation from tax or compliance stakeholders about which identifier should appear for each tested scenario. Do not use the presence of any tax number as the only acceptance criterion; the selected number must also be the correct one.

Testing and activation

Enable the feature first in a sandbox running version 10.0.50. Confirm the activation scope displayed in Feature management and follow the organization’s normal feature-governance process.

A practical test matrix should cover:

1. domestic and foreign customers;
2. taxable and tax-exempt customers;
3. customers with one and multiple tax registrations;
4. prepayment invoices created from each supported business process;
5. posting, printing, reprinting, and electronic delivery;
6. feature disabled versus enabled;
7. standard output versus customized output;
8. newly created versus existing prepayment documents.

For each case, compare:

• customer master data;
• the value stored or referenced by the prepayment transaction;
• the posted invoice record;
• the rendered PDF or printed document;
• the electronic message, where applicable.

Regression testing should also confirm that amounts, sales tax, voucher postings, payment references, and settlement behaviour remain unchanged.

Checks after production deployment

After enabling the feature in production:

• review the first prepayment invoices from each affected legal entity;
• verify the selected tax number against approved customer master data;
• monitor document-generation and electronic-invoice errors;
• ask Accounts receivable users to report unexpected blanks or incorrect registrations;
• retain before-and-after examples as deployment evidence;
• update operating procedures that previously required manual correction.

If an incorrect number appears, investigate registration selection and address context before assuming that the feature itself is defective. Multiple customer registrations can make the expected result dependent on configuration and transaction data.

Consultant assessment

This is a small but useful document-quality correction. It aligns sales prepayment invoices more closely with the tax identification already maintained for the customer and reduces manual intervention in a process that often precedes payment receipt.

The main implementation risk is not activation. It is assuming that every report, localization, and electronic format will display the corrected value without validation. A focused sandbox test using real registration patterns and actual document formats is therefore appropriate.

References

• Microsoft Learn: What’s new or changed in Dynamics 365 Finance version 10.0.50