Dynamics 365 Finance 10.0.49: Evaluating Line-Level Customer Prepayments

Overview

Microsoft Dynamics 365 Finance version 10.0.49, planned for September 2026, introduces a new option for customer prepayment invoices in Accounts receivable. When the supporting feature is enabled, an Accounts receivable parameter can be used to select whether prepayments are calculated for the overall document or at individual line level.

The change is relevant to organizations that request money from customers before goods or services are fully invoiced or delivered. It is particularly useful where the lines on one commercial document do not all have the same prepayment requirement.

This is a parameter-controlled capability rather than a mandatory replacement of the existing process. Organizations should therefore treat its introduction as a process design decision, not simply as a technical update task.

What changes in version 10.0.49

Before this enhancement, the customer prepayment invoice capability calculated the prepayment at document header level. That approach treats the invoice or order as one calculation base from a prepayment perspective.

Version 10.0.49 adds a choice between two calculation scopes:

• Header level: The prepayment continues to be determined for the document as a whole.
• Line level: The prepayment is determined with reference to individual document lines.

The parameter is available only when the Prepayment customer invoice feature is enabled in Feature management.

The update should not be interpreted as a change to customer payment formats or bank message generation. Based on the available release information, there is no stated modification to ISO 20022 files, payment references, bank statement import, or reconciliation formats.

Why line-level calculation is an improvement

Header-level calculation is sufficient when every line follows the same commercial conditions. For example, a customer may be required to pay 20 percent in advance for an entire order.

It becomes less convenient when an order combines different types of lines, such as:

• Stock items requiring an advance payment.
• Services invoiced only after completion.
• Freight or administrative charges excluded from the advance payment agreement.
• Lines with different delivery dates or project milestones.
• Items governed by different contractual percentages.

Under a header-based model, users may need to restructure the source document, create separate documents, or perform manual calculations outside Dynamics 365 Finance. These workarounds increase the risk of discrepancies between the commercial agreement, the prepayment request, and the final customer balance.

A line-level model can provide a more suitable calculation boundary. It should allow the prepayment process to follow the composition of the transaction instead of treating all lines identically.

The main expected improvements are:

• Better alignment between the prepayment request and the underlying goods or services.
• Clearer review of which transaction lines contribute to the requested amount.
• Less need to split documents solely because prepayment conditions differ.
• Reduced dependence on spreadsheets or manual calculations.
• Better support for partial delivery and milestone-oriented scenarios, subject to sandbox confirmation.

The pain point removed

The core pain point is not the ability to request a prepayment. That capability already exists. The limitation is the calculation granularity.

When the business agreement applies at line level but the system calculates at header level, users must bridge the difference operationally. Typical symptoms include:

1. Sales or Accounts receivable users split one commercial transaction into multiple documents.
2. Finance recalculates the requested amount outside the system.
3. Users manually compare prepayment invoices with order lines.
4. Exceptions appear when quantities, prices, or lines change after the prepayment request.
5. Cash application teams need additional context to understand what the incoming amount covers.

Line-level calculation addresses the mismatch between a detailed commercial document and a document-wide prepayment basis. It does not necessarily remove every manual step. The actual result depends on how Dynamics 365 Finance handles later changes, final invoicing, settlement, and cancellations.

Behaviour that must be verified

Microsoft's short feature description leaves several implementation details open. The following points should be recorded as assumptions until they have been tested:

• How the prepayment percentage or amount is assigned to individual lines.
• Whether different lines can use different percentages or only differ by inclusion in the calculation.
• How charges, discounts, sales tax, and rounding affect line-level amounts.
• What happens when a line is added, deleted, repriced, or reduced after the prepayment invoice is created.
• How partial delivery or partial invoicing consumes the prepayment.
• Whether line references remain visible in vouchers, customer transactions, inquiries, and printed documents.
• How credit notes and cancellations reverse line-level prepayments.
• Whether switching the parameter affects existing documents or only newly created transactions.
• What default value Microsoft applies after the update.

Who is affected

Business roles

The change may affect:

• Accounts receivable clerks, who create, post, monitor, or settle customer prepayment invoices.
• Sales order processors, if the prepayment process originates from sales documents.
• Credit controllers, who review whether contractual advance payments have been received.
• Cash application teams, who match incoming customer payments to open transactions.
• Finance managers, who own customer accounting policies and reconciliation controls.
• Solution architects and functional consultants, who configure the feature and assess integrations or reporting effects.
• Auditors and internal control owners, where prepayments are subject to approval or reconciliation controls.

Processes

Review any process involving:

• Customer prepayment requests.
• Sales documents containing lines with different advance-payment conditions.
• Final invoicing after an advance payment.
• Customer payment settlement and reconciliation.
• Changes to orders after a prepayment invoice has been issued.
• Customer-facing invoice layouts and supporting documentation.
• Reporting that compares prepayments with sales orders or invoice lines.

Legal entities

Accounts receivable parameters are generally maintained per legal entity. Each company should therefore be assessed separately.

A group-wide activation may not be appropriate when legal entities have different contractual practices, localization requirements, tax treatments, or customer document designs. The decision should be based on each entity's process rather than enabled globally without review.

What to do before the update

1. Identify current usage

Determine which legal entities use the customer prepayment invoice process. Collect examples of simple and complex cases, including documents with mixed line types and subsequent changes.

Also identify current workarounds. Document splitting and spreadsheet calculations are strong indicators that line-level handling may be useful.

2. Review dependencies

Confirm the status of the Prepayment customer invoice feature in Feature management. The new parameter depends on this feature.

Check customizations and integrations that use:

• Sales or invoice line values.
• Customer prepayment amounts.
• Customer transaction settlement.
• Invoice print management.
• Data entities or reports related to prepayments.

3. Define the expected accounting result

For each test scenario, document:

• Source lines and values.
• Expected prepayment basis.
• Expected tax and rounding treatment.
• Expected customer open transaction.
• Expected settlement against the final invoice.
• Expected general ledger vouchers.

This provides an auditable basis for deciding whether observed behaviour is correct.

Sandbox test plan

Use a version 10.0.49 sandbox with production-like configuration. Test both parameter settings so that the difference is understood.

A minimum test matrix should include:

1. One line with a straightforward prepayment.
2. Multiple lines with the same commercial condition.
3. Mixed item, service, and charge lines.
4. Lines with different quantities, prices, discounts, and tax groups.
5. A line added after the prepayment document is prepared.
6. A quantity or price changed after preparation.
7. Partial delivery followed by partial invoicing.
8. Cancellation and credit correction.
9. Customer payment import and settlement.
10. Final invoicing and reconciliation to the general ledger.

For cash application, verify that the customer transaction and payment reference remain sufficient for matching incoming funds. If ISO 20022 bank statements are imported, run the existing reconciliation scenario as a regression test even though the feature is not described as changing ISO 20022 processing.

What to do after the update

After deploying version 10.0.49:

1. Confirm that the prerequisite feature remains enabled as intended.
2. Locate and review the new Accounts receivable parameter in every relevant legal entity.
3. Record the default value before changing it.
4. Activate line-level handling only in legal entities that have completed acceptance testing.
5. Create a new test transaction and confirm that the selected calculation scope is applied.
6. Reconcile the prepayment invoice, customer transaction, settlement, and ledger voucher.
7. Verify customer-facing documents and operational reports.
8. Monitor the first production transactions through final invoicing and settlement.

Existing open prepayment documents require particular care. Because the release description does not state whether changing the parameter recalculates or otherwise affects existing documents, avoid changing the setting while relevant documents are being processed unless sandbox testing has established the outcome.

Practical assessment

The feature is a focused improvement for organizations whose customer prepayment agreements are more detailed than their current system calculation. Its value is likely to be highest where mixed commercial conditions regularly occur on the same document.

The parameter should not be enabled merely because it is new. If a legal entity uses one prepayment percentage for every line and has no document-splitting problem, header-level processing may remain the simpler option.

The appropriate decision is based on calculation accuracy, user clarity, accounting results, and compatibility with settlement and reporting. Version 10.0.49 provides the additional configuration choice; sandbox validation determines whether it fits the organization's process.

References

• Microsoft Learn: What's new or changed in Dynamics 365 Finance version 10.0.49