Electronic Reporting in D365 Finance: Building Custom Formats Without Code

Every finance team eventually gets the same request: "The bank needs the payment file in this exact layout." A few years ago that meant an X++ developer, a new outbound format class, and a deployment for every tweak. The Electronic Reporting (ER) framework changed that. ER lets a functional consultant build and version file formats — CSV, fixed-width, XML, JSON — entirely through configuration. Here is how the pieces fit and how to build one.

The four ER building blocks

ER separates what data you have from what the file looks like. That separation is the whole point, and it is why one data model can feed dozens of formats.

Component	Role	Owned by
Data model	An abstract, format-agnostic structure of the data	Microsoft (mostly)
Model mapping	Binds the data model to real F&O tables/fields	Microsoft or you
Format	The concrete file layout that consumes the model	You
Format mapping	Connects format elements to model nodes	You

You rarely build a data model from scratch. Microsoft ships rich ones — for example the "Payment model" used by vendor payment formats. You derive a format from that model and bind its elements.

Configuration providers and the repository

Before building anything, set your configuration provider under Organization administration > Electronic reporting > Configuration providers, and mark it active. The provider is the "author" stamped on everything you create. Pull Microsoft's base configurations from the Global repository, then build your derived format in your own provider so upgrades never clobber it.

The hierarchy matters: your format is a child of Microsoft's model. When Microsoft ships a new model version, you rebase your format onto it rather than rewriting.

Building a custom CSV payment format

Suppose the bank wants a comma-separated file: header row, one line per payment, trailer with a total. Steps:

1. Create a format derived from the Payment model. In the format designer, add a root with three sequences: Header, Lines, Trailer.
2. Add fields under each. For the lines sequence, bind to the model's payment node so it repeats per payment.
3. Bind elements to model nodes in the Mapping tab. Each leaf gets a formula.

ER formulas look like Excel crossed with a data dictionary:

// Format a date the bank expects
DATEFORMAT(model.Payments.PaymentDate, "yyyyMMdd")

// Pad an account number to 10 chars
PADLEFT(model.Payments.CreditorAccount, 10, "0")

// Sum all payment amounts for the trailer
SUMIF(model.Payments, model.Payments.Amount, model.Payments.Amount <> 0)

The Lines sequence iterates automatically because it is bound to a repeating model node — you do not write a loop.

Enabling the format for a payment method

A format alone does nothing. Wire it up:

• For vendor payments: Accounts payable > Payment setup > Methods of payment, set Generic electronic export format and pick your ER format.
• Run the payment proposal and generate the file. ER renders it on the spot.

For non-payment scenarios (custom exports, integrations), call the format from an ER "format mapping to destination" or invoke it from code with ERObjectsFactory.

Versioning and lifecycle

ER configurations are versioned with Draft and Completed states. Edit in Draft; mark Completed to make a version usable in production. Once Completed, a version is immutable — to change it you create a new Draft from it. This gives you a clean audit trail and safe rollback: if the bank rejects the new layout, you point the payment method back at the previous Completed version.

Export your configurations to source control or LCS as XML. They are data, not code, so they move with a configuration package or the ER import/export, not with your deployable package.

Tips from production

• Test with real volume. ER renders in memory; a million-line export can be slow if your model mapping pulls unindexed fields. Profile the mapping query, not just the format.
• Keep formulas readable. Long nested IF chains are a maintenance trap. Push reusable logic into the model mapping's calculated fields so the format stays declarative.
• Watch culture settings. Number and date formatting honor the format's culture. A decimal comma versus point has failed more bank submissions than any logic bug.
• Derive, never edit Microsoft's. If you change a base configuration in place, the next repository update will fight you. Always work in your provider.

ER has a learning curve, but the payoff is real: when the bank changes the spec next quarter, you ship a new format version in an afternoon instead of scheduling a code deployment.