Dynamics 365 Finance: PEPPOL Type 386 and Saudi Prepayment E-Invoicing Arrive March 2027

For ERP architects, finance controllers, and compliance administrators operating in multi-national environments, the change is more than a minor formatting tweak. In Saudi Arabia specifically, Microsoft is retiring the generation of electronic invoices from payment transactions in favor of invoice-driven prepayment documents, excluding reversal prepayment invoices from e-invoice generation, and ensuring final electronic invoices explicitly account for and reference the original advance bills. Because the feature requires administrator or maker activation and carries a March 2027 General Availability target on the Microsoft 365 Roadmap, technical teams have a clear runway to audit their Electronic Reporting (ER) mappings and Accounts Receivable workflows before flipping the switch.

What Roadmap ID 576769 Changes in Globalization Studio​

At the heart of this update is how Dynamics 365 Finance translates a commercial advance payment request into a legally compliant electronic document. When organizations use the Customer prepayment invoice capability on sales orders, they are issuing a formal billing document for a deposit—either a fixed amount or a percentage of the total order—before goods or services are delivered. Until now, aligning that internal Dynamics 365 Finance document with external clearance and post-audit e-invoicing mandates required careful navigation of country-specific workarounds.

According to Microsoft's roadmap specification for ID 576769, the new Globalization Studio capability focuses strictly on customer prepayment invoices created from sales orders and introduces two distinct compliance paths:

• PEPPOL-Based Electronic Invoicing: The system generates dedicated PEPPOL electronic invoices of type 386 (the standard UN/CEFACT document type code for a prepayment invoice) whenever an original customer prepayment invoice is posted.
• Saudi Arabia Electronic Invoicing: Original customer prepayment invoices also generate type 386 electronic invoices. In addition, the Saudi localization enforces three lifecycle rules:
  1. Reversal Exclusion: Reversal prepayment invoices are excluded from electronic invoice generation.
  2. Final Invoice Reconciliation and Referencing: When the final sales order invoice is issued, its electronic invoice takes the prepaid amounts into account and embeds a reference to the original prepayment invoice(s).
  3. End of Payment-Transaction E-Invoicing: The system discontinues the generation of electronic invoices based on payment transactions.

Section Summary: Roadmap item 576769 standardizes sales-order prepayment e-invoicing around document type 386 for PEPPOL and Saudi Arabia, while introducing strict lifecycle rules for Saudi deployments that tie final e-invoices back to original prepayment invoices and halt e-invoice generation from payment journals.

Why Moving Away from Payment-Transaction E-Invoices Matters​

If you have ever configured electronic invoicing parameters in Dynamics 365 Finance for Middle Eastern or European legal entities, you know that the underlying table context determines when and how an XML or JSON payload is built. Why is Microsoft explicitly discontinuing electronic invoice generation based on payment transactions in the Saudi scenario?

A look at Microsoft Learn's documentation for Configure Electronic invoicing parameters reveals the architectural backstory. Historically, the standard Electronic Document Parameters table configured Saudi Arabian ZATCA submissions for prepayments against the LedgerJournalTrans table, using a document context labeled Prepayment invoice context and an Electronic Reporting mapping called Customer prepayments. In plain English, that legacy pattern looked at the payment journal transaction (LedgerJournalTrans) rather than a structured sales-order prepayment invoice journal.

By contrast, standard customer invoices across Austria, Belgium, Germany, PEPPOL, and Saudi Arabia are mapped against CustInvoiceJour using the Customer invoice context. Meanwhile, Microsoft has steadily matured the dedicated Prepayment customer invoice feature in Accounts Receivable—including adding a line-level prepayment flow parameter (Enable line level prepayment flow) starting in Dynamics 365 Finance version 10.0.49.

In the standard Dynamics 365 Finance prepayment workflow documented on Microsoft Learn, an invoice and a payment are two separate accounting events:

1. Prepayment Invoice Creation: The seller confirms a sales order, generates a prepayment proposal (percentage or fixed amount), and posts a Prepayment invoice. This debits Accounts Receivable and credits a Prepayment (Deposit) ledger account.
2. Payment Settlement: When the buyer actually wires the funds, the finance team posts a customer payment journal to settle that open prepayment invoice, moving the status to Received.
3. Application to Final Invoice: When the order ships and the final invoice is posted for the full order value, the settled prepayment is applied against it—either in real time via Synchronous prepayment settlement or via the background Automated prepayment settlement posting process automation job—leaving only the net unpaid balance open for collection.

It is critical for IT and finance teams not to misread Microsoft's roadmap phrasing. Discontinuing the generation of electronic invoices based on payment transactions does not mean customer payment journals or payment settlements are going away in Dynamics 365 Finance. You still use a customer payment journal to record the cash receipt and settle the prepayment invoice. What changes in the Saudi e-invoicing flow is the trigger for regulatory reporting: the electronic document is generated from the original customer prepayment invoice itself (as a type 386 document), and the final electronic invoice deducts and references that advance bill, rather than firing off an e-invoice when a payment journal line is posted.

Section Summary: Shifting Saudi prepayment e-invoicing away from payment transactions aligns regulatory reporting with the formal sales-order prepayment invoice lifecycle, leaving standard customer payment journals intact for cash settlement while eliminating duplicate or payment-triggered e-invoice submissions.

How Dynamics 365 Finance Handles Customer Prepayment Invoices Under the Hood​

Because the new Globalization Studio capability builds directly on Customer prepayment invoices created from sales orders, organizations planning to adopt roadmap ID 576769 should ensure their foundational Accounts Receivable prepayment configuration is clean and up to date. Based on Microsoft Learn's official customer prepayment invoice documentation, here is how the underlying feature is structured and configured in Dynamics 365 Finance:

1. Core Feature and Parameter Setup​

Before a user can generate a prepayment invoice on a sales order, administrators must configure the environment across four areas:

• Feature Management: Enable the Prepayment customer invoice feature in the Feature management workspace. (Organizations running Dynamics 365 Finance version 10.0.49 or later can also enable Enable line level prepayment flow under Accounts receivable > Setup > Accounts receivable parameters > Updates > Invoice to track prepayments per sales order line rather than only at the order header.)
• Posting Profiles: Navigate to Inventory management > Setup > Posting > Posting > Sales order > Prepayment and assign the default ledger account with the type set to Customer prepayment.
• Accounts Receivable Parameters: Under Accounts receivable > Setup > Accounts receivable parameters, on the Updates tab (Invoice FastTab, Prepayment section), administrators can enforce Check mandatory sales order confirmation and enable Synchronous prepayment settlement for real-time application during final invoicing. On the Ledger and sales tax tab, the Prepayment application policy can be set to either Notification (manual application with a prompt at final invoicing) or Automatic (auto-applied once full payment settles the prepayment invoice).
• Number Sequences: Dedicated number sequences must be defined on the Number sequences tab for Prepayment invoice, Prepayment invoice voucher, Prepayment invoice reversal, and Prepayment invoice reversal voucher references.

2. Electronic Reporting and Globalization Studio Integration​

In Dynamics 365 Finance, electronic invoices are generated by Electronic Reporting (ER) models and metadata before being transmitted to the Electronic Invoicing service managed in Globalization Studio.

• Standard printable prepayment forms rely on importing Customer prepayment invoice model xml, Customer prepayment invoice model mapping xml, and Prepayment invoice template xml from Dataverse in the Electronic reporting workspace.
• For government e-invoicing pipelines, administrators import the relevant Customer invoice context model and Invoice model mapping configurations from the Dataverse repository inside the Globalization Studio workspace, and bind them under Organization administration > Setup > Electronic document parameters.
• By default, Electronic document parameters apply across all legal entities in an environment unless the Electronic documents configuration per legal entities feature is enabled in Feature management.

3. Reversals and Final Invoice Application​

In day-to-day operations, if a posted prepayment invoice needs to be canceled before fulfillment, users can select Reverse transaction on the action pane and supply a reversal posting date, reason code, and comment. Under the new Saudi e-invoicing rules in roadmap ID 576769, those reversal prepayment invoices are explicitly excluded from generating an electronic invoice. When the order proceeds normally to final billing, expanding the Prepayment invoice FastTab on the final invoice confirms the applied deposit, and the new Globalization Studio logic ensures the outbound final e-invoice reflects the prepayment deduction and references the original type 386 prepayment invoice.

Section Summary: The e-invoicing update relies on the native Accounts Receivable prepayment invoice framework—spanning Feature Management, AR posting parameters, number sequences, and Globalization Studio ER repositories—to connect sales order deposits with compliant outbound electronic documents.

Timeline, Rollout Scope, and What Admins Should Prepare Now​

According to the Microsoft 365 Roadmap entry (ID 576769, published October 16, 2026), this capability is currently In development for Dynamics 365 Finance on the Web platform across Worldwide (Standard Multi-Tenant) cloud instances, with a scheduled General Availability date of March 2027.

Administrators who closely track Microsoft's documentation should note a timeline nuance: while the archived 2026 Release Wave 1 plan on Microsoft Learn (which covered April through September 2026 and was archived in October 2026) previously referenced earlier wave timing for prepayment and e-invoicing enhancements, the live Microsoft 365 Roadmap entry updated in October 2026 places General Availability for ID 576769 at March 2027. Because Microsoft notes that roadmap dates are estimates subject to change, implementation teams should track ID 576769 directly on the Microsoft 365 Roadmap and verify the updated ER configuration versions in Globalization Studio before scheduling production cutovers.

To prepare smoothly ahead of the March 2027 rollout, Dynamics 365 Finance administrators and solution architects should take four practical steps:

1. Audit Current Prepayment Habits: Identify whether your legal entities operating in PEPPOL jurisdictions or Saudi Arabia are issuing prepayments via formal sales-order Prepayment invoices or recording deposits directly through raw LedgerJournalTrans customer payment journals. Only sales-order customer prepayment invoices are covered by this roadmap item.
2. Review Saudi ZATCA ER Mappings: If your Saudi legal entity currently uses the LedgerJournalTrans Prepayment invoice context mapping in Electronic document parameters, plan for a transition in your test sandbox once Microsoft publishes the updated Globalization Studio configurations, since payment-transaction-based e-invoice generation is being discontinued for that scenario.
3. Check Legal Entity Parameter Scope: Verify whether Electronic documents configuration per legal entities is active in Feature management so that testing new PEPPOL or Saudi prepayment mappings in a multi-entity tenant does not unexpectedly alter document generation for other countries.
4. Validate Reversal Operational Procedures: Ensure your Accounts Receivable staff in Saudi Arabia understand that reversal prepayment invoices inside Dynamics 365 Finance will not trigger outbound electronic invoices under the new model, and align internal audit procedures accordingly.

By tying electronic prepayment invoices directly to sales-order billing documents and standardizing on type 386 payloads, Microsoft is taking another step toward eliminating manual tax reconciliation between ERP ledgers and government clearance platforms. Keep an eye on your Globalization Studio Dataverse repositories as March 2027 approaches—and let us know in the WindowsForum community how your finance teams are handling PEPPOL and ZATCA e-invoicing transitions.