How to Integrate D365 F&O with E-Invoicing Intermediaries Using Azure
Introduction
Electronic invoicing is a key requirement in many Dynamics 365 Finance & Operations (D365 F&O) implementations, especially when invoices must be transmitted to certified intermediary platforms such as Pagero, Comped, or similar providers.
A common mistake is implementing direct and tightly coupled integrations between D365 F&O and the intermediary: custom X++ code, synchronous API calls, or batch jobs pushing files to external systems.
While these approaches may work initially, they often lead to scalability issues, poor resiliency, and high maintenance costs over time.
In this article, I describe a modern, event-driven architecture based on Azure services that enables a scalable, reliable, and loosely coupled electronic invoicing process.
This is the first article in a series:
- Part 1 – Architecture overview and benefits (this article)
- Part 2 – Configuring Electronic Reporting (ER) and ER Destinations
- Part 3 – Azure Service Bus, Blob triggers, and Azure Functions
The Problem with Direct Integrations
From a functional perspective, the requirement seems simple:
generate a compliant XML invoice and send it to an intermediary.
However, direct integrations from D365 F&O typically introduce several issues:
- Strong coupling between ERP and intermediary
- Custom X++ integration logic that is hard to test and maintain
- Limited error handling and retry mechanisms
- Poor scalability under high invoice volumes
- High effort when changing or adding intermediaries
Embedding integration logic directly into F&O also increases complexity during platform updates and reduces overall system stability.
Architecture Goals
The main architectural goals are:
- D365 F&O focuses only on document generation
- External transmission is handled by dedicated integration services
- The intermediary becomes an implementation detail, not a dependency
- The solution is asynchronous, resilient, and scalable
To achieve this, an event-driven architecture is the ideal choice.
Proposed Architecture Overview
The solution is composed of the following components:
- Electronic Reporting (ER) in D365 F&O
- Electronic Reporting Destination targeting Azure Blob Storage
- Blob event notification
- Azure Service Bus Queue
- Azure Function triggered by the queue
- Delivery to the intermediary (SFTP, REST API, etc.)
End-to-End Process Flow
- D365 F&O generates the electronic invoice XML using Electronic Reporting
- The XML file is automatically stored in Azure Blob Storage
- The file creation raises an event sent to a Service Bus Queue
- An Azure Function is triggered by the queue message
- The function retrieves the XML file from Blob Storage
- The invoice is transmitted to the intermediary (e.g. via SFTP)
Why Azure Blob Storage Is a Key Integration Point
Azure Blob Storage acts as more than just file storage:
- Durable persistence of fiscal documents
- Full auditability and traceability
- Ability to reprocess invoices without regenerating them
- Temporal decoupling between invoice creation and delivery
If downstream systems are unavailable, invoices are not lost and can be safely reprocessed.
The Role of Azure Service Bus Queue
The Service Bus Queue is the backbone of the event-driven model:
- Guaranteed message delivery
- Automatic retry handling
- Built-in support for Dead Letter Queues
- Natural buffering during peak loads
This ensures that invoice transmission is fully asynchronous and resilient, without impacting ERP performance.
Key Benefits of This Architecture
Loose Coupling
D365 F&O has no knowledge of the intermediary or transmission protocol.
Scalability
High invoice volumes can be processed without stressing the ERP.
Maintainability
Changing the intermediary only affects the Azure Function, not F&O.
Reliability
Retries, logging, and DLQ handling provide robust error management.
Reusability
The same pattern can be reused for:
- Sales orders
- Credit notes
- Delivery notes
- Other fiscal documents
Comparison with Alternative Approaches
| Approach | Pros | Cons |
|---|---|---|
| Direct API calls from F&O | Simple | Tight coupling, low resiliency |
| Batch jobs + FTP | Easy to implement | Poor scalability, limited monitoring |
| Event-driven Azure architecture | Scalable, resilient, clean | Higher initial setup |
The initial investment is quickly repaid in medium- to long-term projects.
When This Architecture Might Be Overkill
This approach may be unnecessary if:
- Invoice volumes are very low
- The intermediary is strictly temporary
- No scalability or audit requirements exist
In most enterprise scenarios, however, it represents a future-proof solution.
Conclusion
Separating invoice generation from invoice delivery is a winning architectural choice.
Dynamics 365 Finance & Operations remains focused on its core domain, while Azure provides the ideal platform for building robust and scalable integrations.
In the next article, we will dive into the configuration of Electronic Reporting and ER Destinations, showing how to generate compliant XML invoices and store them in Azure Blob Storage.