Electronic Reporting (ER)
Electronic Reporting (ER) is a configurable framework for generating and parsing structured electronic documents in Dynamics 365 Finance & Operations. It handles regulatory filings, payment files, tax declarations, e-invoices, bank statement imports, and other data exchange formats — all without requiring X++ development.
ER is designed for functional consultants and power users who configure document formats through a visual designer in the D365 client. Developers interact with ER primarily when extending data model mappings or invoking ER formats programmatically.
Unlike SSRS reports, Electronic Reporting has no AOT object definitions. ER configurations (models, mappings, formats) are stored as XML configuration files managed through the Electronic reporting workspace in D365, not as traditional AOT objects. This page provides an architectural reference rather than an AOT property reference.
Architecture — Model, Mapping, Format
ER follows a strict three-layer architecture that separates the business data structure from the physical data sources and from the output format:
Data Model
The data model defines the abstract business data structure — a tree of records and fields that represents the information a document needs. Data models are format-agnostic: the same model can feed multiple output formats.
For example, a "Payment" data model might define:
PaymentHeader(company, bank account, payment date)PaymentLines(vendor account, amount, currency, reference)PaymentTax(tax code, tax amount)
Data models are versioned and published by a configuration provider (Microsoft, ISV, or customer).
Model Mapping
A model mapping connects the abstract data model to concrete D365 data sources — tables, classes, calculated fields, and enumerations. The mapping defines how each model node gets its data at runtime.
Model mappings are what developers most commonly extend. A mapping can reference:
- Table records — direct queries against D365 tables.
- Calculated fields — expressions that compute values from other data sources.
- Data model relations — navigating parent-child relationships in the model tree.
- User input parameters — runtime parameters prompted to the user.
Format
The format defines the physical output layout — the structure, elements, and expressions that produce the final document. Formats support multiple output types:
| Output Type | Description |
|---|---|
| XML | Structured XML documents (e.g., EU VAT returns, Intrastat declarations). |
| JSON | JSON payloads for API integrations and data exchange. |
| Excel | Excel workbooks using template-based generation. |
| Text / CSV | Fixed-width or delimited text files (e.g., bank payment files, SEPA credit transfers). |
| Word | Word documents using template-based generation. |
| PDF output by converting from other formats or using templates. |
ER vs SSRS — When to Use Which
| Criterion | SSRS Reports | Electronic Reporting |
|---|---|---|
| Primary audience | Developers (X++ / Visual Studio) | Functional consultants (visual designer) |
| Output types | Paginated print documents (PDF, HTML, Excel, Word) | Structured data files (XML, JSON, Excel, text, Word, PDF) |
| Design tool | Visual Studio / AOT | ER Format Designer in D365 client |
| Data access | RDP classes, AOT queries | ER model mappings (tables, calculated fields) |
| Versioning | AOT model store / source control | ER configuration versions in D365 |
| Localization | Label files, SSRS parameters | ER configuration derivatives per country/region |
| Typical use cases | Invoices, packing slips, financial statements | Tax filings, payment files, e-invoices, regulatory reports |
| Extensibility | Class extensions, CoC on RDP/controller | Derived configurations, model mapping extensions |
Use SSRS when you need a paginated, print-ready document designed for human reading. Use ER when you need a structured data file for machine consumption or regulatory filing.
Working With ER in Code
Running an ER Format Programmatically
Developers can invoke an ER format from X++ using the ERFormatMappingRunByFormatMappingId class:
Extending a Model Mapping
To add custom data to an existing ER configuration without modifying the base, create a derived configuration:
- In the Electronic reporting workspace, select the base configuration.
- Choose Create configuration → Derive from name: <Base config>.
- In the derived mapping designer, add new data sources and bind them to the model.
This approach preserves upgradeability — Microsoft-provided base configurations can be updated independently of customer extensions.
ER Destinations
ER destinations control where the generated document goes after execution:
| Destination | Description |
|---|---|
| File | Save to Azure Blob Storage or SharePoint. |
| Send as an email attachment. | |
| Print archive | Store in the D365 print archive. |
| Screen | Display in the browser for download. |
| Power BI | Push data to a Power BI dataset. |
Destinations are configured per format component in the Electronic reporting destination page and can be conditional (e.g., send invoices over $10,000 by email, all others to print archive).
Configuration Lifecycle
ER configurations follow a lifecycle that supports multi-party development and safe upgrades:
- Draft — a new or modified configuration version being edited.
- Completed — a finalized version ready for use or sharing.
- Shared — published to the Global Repository (Microsoft Regulatory Configuration Service).
- Discontinued — marked as end-of-life; existing versions still work but no new versions expected.
Customers can import configurations from the Global Repository or a Connected application, then create derived versions for customization.