A Microsoft reference architecture guides the design of internal support with Copilot Studio. Permissions, escalation, and testing shape what is worth automating.
Business Central 29 combines controls over selectable layouts with APIs for querying the report inbox, retrieving files and updating their read status.
Microsoft lists three enhancements in public preview: multiple excise duties per item, withholding on employee transactions and vendor-specific self-billing number series. Their application depends on the process and configuration.
BC29 adds purchase order instructions, assisted setup and new warehouse options for subcontracting, building on capabilities already available in 28.3.
GitHub adds optional comparisons to the Copilot impact dashboard. The indicators place adoption and pull request merge rates alongside participating peers, with limits worth understanding before setting targets.
OpenAI’s policies will require prior approval to give third parties direct access to its models from November 20, 2026. The text distinguishes this service from integrating models into an application.
Checked on 27 October 2026 against public Microsoft and OpenPeppol documentation. BC29 classifies EDI exchange as public preview. The video is retained as the originating source, but its walkthrough and a transcript could not be inspected. The example and test matrix are synthetic proposals from Nexo, without implementation results.
Microsoft includes EDI document exchange among the E-Documents capabilities in Dynamics 365 Business Central 29.0. The BC29 release notes classify it as public preview.
Roadmap entry 573305 describes order exchange and sending remittance advice using Peppol BIS 3, with scope to extend formats and document types. It lists October 2026 for preview and April 2027 for the planned rollout start. This is a planning schedule: it does not establish current general availability or access in every environment.
From the order to the commercial response
The Peppol BIS Ordering standard provides for a buyer sending an order and a seller responding. It distinguishes acknowledgement of receipt, acceptance, rejection and acceptance with changes.
That distinction matters when designing tests: receiving an order does not mean accepting it. The standard's capabilities also do not establish that the Business Central preview implements every variant. The pilot should establish which messages and statuses the specific combination of version, format and connector supports.
A pilot with two fictional companies
Synthetic example: Compras Norte orders 20 boxes from Suministros Sur. Both companies, their names and the transaction are fictional. The test objective would be to trace the relationship between the buyer's purchase order, the seller's sales order and the response returned to the buyer.
This matrix proposes checks; it does not describe completed tests or guarantee automatic product behaviour.
Test
What to check
Proposed owner
Valid order
Compare the 20 boxes, references, unit, price and delivery details at both ends.
Purchasing and sales
Acceptance
Link the response to the original order and check its effect on the buyer's side.
Sales and purchasing
Rejection
Check where the reason appears and who decides to correct or close the request.
Sales and purchasing
Incomplete data
Introduce an unmapped reference and identify the validation and its owner.
Master data and integration
Resubmission
Repeat the same transmission in testing and check duplicate handling.
Integration support
What the connection requires
The external service connection guide requires E-Document Core and a connector. It lists Avalara, B2BRouter, Continia, Logiq, Pagero, SignUp and ForNAV, and explains that a provider contract is required and additional licensing or payments may apply. This is a general E-Documents list; it does not independently certify BC29 order and response support with every provider.
The E-Documents setup guide explains how to inspect the document types supported by the selected format. For the pilot, record the format and connector used, both parties' identifiers, item and unit mappings, and sending and review rules. The general documentation does not constitute an EDI compatibility matrix by provider and country.
What evidence to retain and which limits to maintain
Microsoft documents a document log and an integration log: the former records creation and processing; the latter records communications and status updates involving external services. Both provide starting points for reconstructing an incident, according to the E-Documents FAQ.
As a test criterion, Nexo proposes retaining related identifiers, observed statuses and the intervention needed to resolve each exception. Support for a local invoicing format does not establish order exchange coverage or compliance with every requirement in a country. The consulted sources also provide no implementation costs, processing times or measured improvements for this pilot.
Nexo's interpretation
The functional interest lies in establishing whether the exchange avoids re-entering data and makes the order's commercial status visible. These are potential benefits that need measurement. A useful pilot also needs to demonstrate how a rejection is recognised, how data is corrected and who takes responsibility when the flow stops.
Created with AI assistance and reviewed by Nexo Community. Practical proposals and editorial interpretation are distinguished from documented facts.