Skip to content
Sentinel 1.5 | Preview

Support customer prepayment invoices in e-invoicing

2026 Release Wave 1 · E-Invoicing

Score 72/100 · HighImpact HighSwiss relevance LowRemoved

Dx365 Analysis

Our interpretation — not a Microsoft statement

What is changing?

The e-invoicing framework is being extended to recognise sales-order customer prepayment invoices as their own electronic document scenario. The planned design uses invoice type code 386 for original prepayment invoices in PEPPOL-based processing and Saudi Arabian processing. Saudi processing will omit reversal prepayment invoices, while the final invoice will reflect the prepayment and link back to the earlier document. Existing Saudi designs that create electronic documents from customer payment transactions will need review because that approach is planned to end.

Dynamics 365 Finance can post customer prepayment invoices from sales orders, but standard e-invoicing coverage does not currently provide complete handling of these documents as a dedicated prepayment invoice type across the described scenarios. Implementations that must report prepayments electronically typically rely on country-specific payment-transaction processing, customised Electronic Reporting configurations, service-provider transformations, or manual submission. Linking the final electronic invoice to the original prepayment document may therefore require additional logic outside the standard process.

From the planned September 2026 release, an enabled and configured environment should be able to generate a dedicated type-386 electronic document for an original sales-order prepayment invoice in the stated PEPPOL and Saudi scenarios. In Saudi Arabia, the subsequent final invoice should account for the prepayment and carry references to the original prepayment invoice. Reversal prepayment invoices are not expected to generate their own Saudi electronic document. Payment transactions will no longer serve as the source for generating these electronic invoices.

Why it matters

This closes a process gap between accounts receivable prepayment accounting and regulatory electronic invoicing. It may reduce custom format logic and manual document handling, but it also changes the document trigger for existing Saudi implementations. Incorrect migration could cause missing, duplicate, or poorly referenced electronic invoices, particularly where payment-based generation is already in production.

Who is affected?

Accounts receivable consultantsDynamics 365 Finance solution architectsElectronic Reporting and e-invoicing specialistsAccounts receivable usersSales order administratorsFinance and tax managersIntegration developersSaudi localization consultantsExternal e-invoicing service providersTest and support teams

Consultant impact — High

The feature is narrow in functional scope but can materially change an established compliance flow. Relevant projects will need to review e-invoicing applicability rules, electronic document sources, format mappings, numbering and references, service-provider interfaces, and exception handling. Saudi customers using payment-triggered electronic documents face the greatest impact because migration and regression testing will be required to prevent duplicate or missing submissions.

  • Identify legal entities that use sales-order customer prepayment invoices together with PEPPOL or Saudi e-invoicing.
  • Determine whether any existing electronic document is currently generated from customer payment transactions.
  • Review custom Electronic Reporting formats, applicability rules, integrations, and provider mappings that already handle prepayments.
  • Plan activation and configuration after the capability becomes available; it is not described as automatically enabled.
  • Test original prepayment posting, electronic document creation, submission, rejection and resubmission.
  • For Saudi Arabia, test reversal handling and confirm that no unintended electronic document is submitted.
  • Test final invoices to verify prepayment values, tax treatment, settlement outcome, and references to preceding prepayment invoices.
  • Run duplicate-document and missing-document controls during migration from payment-based generation.
  • Update operating procedures, support documentation, and user training before production adoption.

Swiss relevance — Low

There is no stated Swiss localization, VAT, payment, banking, ISO 20022, reporting, or compliance change. The capability may still help Swiss companies that voluntarily exchange PEPPOL documents or operate legal entities in countries requiring electronic reporting of prepayments, but it does not appear to introduce a Switzerland-specific requirement.

What should customers do now?

  • Add the feature to the roadmap for customers using customer prepayment invoices, even if their Swiss company is not directly affected.
  • Prioritise an impact assessment for Saudi legal entities and multinational deployments with central e-invoicing integrations.
  • Wait for detailed configuration documentation and deployable artifacts before designing a definitive solution.
  • Create test cases covering partial prepayments, multiple prepayments, cancellations or reversals, final invoicing, credit corrections, tax differences, and cross-period processing.
  • Confirm that receiving networks and service providers accept invoice type code 386 and preserve references to the original prepayment document.
  • Avoid new custom development for this gap where the September 2026 timeline is compatible with the customer's compliance deadlines.

Release Radar score — 72/100 (High priority)

The feature has strong relevance for accounts receivable compliance and can remove custom handling for affected customers. Its potential population is smaller than that of general sales invoice changes because it applies specifically to customer prepayment invoices and selected electronic invoicing scenarios. Implementation impact is high for Saudi customers using payment-based generation, while direct Swiss relevance is low. The September 2026 availability date also leaves meaningful preparation time.

Assumptions, not Microsoft-confirmed facts

  • No public preview date is supplied, so behaviour cannot yet be validated in a preview environment.
  • The available description does not clarify whether type 386 support applies to every PEPPOL profile, country implementation, or receiving network.
  • It is assumed that the scope is limited to customer prepayment invoices created from sales orders; treatment of free-text invoices, project invoices, subscription billing, and other advance-billing processes is not specified.
  • The exact enablement mechanism, prerequisite application version, Globalization feature version, and configuration package are not yet stated.
  • Tax calculation, accounting entries, settlement mechanics, numbering, correction handling, and exchange-rate treatment are assumed to remain governed by the underlying Finance processes unless later documentation states otherwise.
  • The end of payment-transaction-based generation is interpreted as relevant to the described prepayment e-invoicing scenario, especially Saudi Arabia, rather than as a universal removal of all payment-related electronic reporting.

Microsoft information

Quoted from the release plan

In the current and upcoming release waves, we continue targeted investments in e‑invoicing to support evolving regulatory mandates and country‑specific requirements. Focus areas include extending coverage for additional clearance and post‑audit scenarios, improving interoperability with government platforms and service providers, and keeping formats and protocols aligned with regulatory changes.

In the current release wave, we are introducing the following e-invoicing capabilities. Handling of customer prepayment invoices in E-invoicing Global and local customers using Customer prepayment invoices in Microsoft Dynamics 365 Finance can now process a dedicated electronic invoice type specifically for customer prepayments. For customer prepayment invoices created from sales orders, the system supports generation of electronic invoices as follows: - PEPPOL-based electronic invoices of type 386 are generated for original customer prepayment invoices. - For Saudi Arabia: - Electronic invoices of type 386 are generated for original customer prepayment invoices. - Reversal prepayment invoices are excluded from electronic invoice generation. - Final electronic invoices take prepayment amounts into account and reference the original prepayment invoices. - Generation of electronic invoices based on payment transactions is discontinued.

Change history

Differences detected between scans

  • removed21 Aug 2026

    The feature is no longer listed on the Microsoft release plan.

    Upcoming
    Removed
  • added12 Aug 2026

    Microsoft added this feature to the Dynamics 365 Finance release plan.

    —
    Upcoming
Back to Release Radar³