eInvoice Sender for Microsoft Dynamics 365 BC - en-US

This documentation covers the essential functions for daily use of DEXPRO eInvoice Sender. For advanced configuration and technical details, refer to the expert setup options and contact support as needed.

System Requirements

System requirements for using eInvoice Sender for Dynamics 365 BC

System Requirements

Supported Microsoft Dynamics 365 Business Central versions

Microsoft Dynamics 365 Business Central integration is possible from the following version due to minimum technical requirements:

Supportet Microsoft Dynamics 365 Business Central Versions

The prerequisite for operation is that the respective Microsoft Dynamics 365 Business Central version is still in regular support. The extended support is excluded.

 

System Requirements

Supported Digivoice Versions

A licensed Digivoice system is required to use the eInvoice Sender in Microsoft Dynamics 365 Business Central and for operation.

License: Valid Digivoice License/Credentials

Installation

Installation

Licenses

Microsoft

Information about the Microsoft Business Central licenses.

DIGIVOICE

The DEXPRO Digivoice system that should be connected to Business Central requires a valid customer license.

Installation

Obtaining the DEXPRO module

Detailed Information are here.

OnPrem

For OnPrem installations, an runtime package with the required apps is provided upon request of a registered reseller / partner. These modules are added to the customer license by the partner and then imported into Microsoft Dynamics Business Central. It should be noted that the DEXPRO Core module forms the basis for all DEXPRO modules and must therefore be imported first.

Cloud

For cloud installations, you only need the Microsoft AppSource. This is where the required DEXPRO modules are downloaded.

Squeeze_icon_appsource.png

Installation

Setup Wizard

This wizard guides the user step by step through the different facilities of the module.

Guided Setup Wizard

  1. Navigate to DEXPRO eInvoice Setup from the search
  2. Click Guided Setup to launch the setup wizard
  3. Follow these steps:

Step 1: Welcome

Step 2: Basic Setup Information

Configure the fundamental settings for electronic invoicing:

Step 3: Payment Information (if Expert Mode enabled)

Step 4: Validation Settings (if Expert Mode enabled)

Step 5: Final Review

Manual Setup Options

Access additional setup through DEXPRO eInvoice Setup page:

Actions Available:

Mappings Section:

Configuration & Administration

Configuration & Administration

Permission sets

In order to use the modules, the appropriate authorization set must be assigned to the respective users.

The following are supplied with:

Users without an eInvoice permission set

Users who do not work with e-invoices do not need an eInvoice permission set. The standard pages and processes the app extends keep working for them, for example the posted sales, service and purchase documents, the purchase credit memo, the Payment Methods and VAT Clauses pages, postings of documents that cannot become an e-invoice (such as purchase invoices or shipments) and emails of such documents. For these users:

Users who post or send documents that become e-invoices (sales and service invoices and credit memos, purchase credit memos), or who work with the e-invoice pages, still need one of the eInvoice permission sets.

Configuration & Administration

DEXPRO Core

The DEXPRO Core manages the individual DEXPRO apps and their documents per client.

All documents that have been entered and processed via the various DEXPRO modules in Microsoft Dynamics 365 Business Central are displayed. A global number series, which is used across all DEXPRO apps, is used to complete individual documents. This offers the advantage that users only have to work with one number series per document.

Further information can be found here.

Configuration & Administration

eInvoice Sender Setup

In the eInvoice Sender setup, both the connection to the DIGIvoice system and the processing within the app are set up.

Menu

Download Configuration

This is used to download the configuration and structure of the e-invoice documents.

Related

Document Queue

You can access the document queue via this menu item.

Process Log

You can access the process log of transactions with Digivoice via this menu item.

Customer Setup

You can access the customer-specific setup via this menu item.

Vendor Setup

You can access the vendor-specific setup via this menu item.

OAuth 2.0 Setup

This menu item takes you to the OAuth 2.0 setup for authentication on the Digivoice system.

Mappings

General

In this FastTab, you can activate/deactivate the use of this app and set up the connection to the Digivoice system.

image-1749194930883.png

Export Settings

The standards for the export are saved here.

image-1749194946937.png

XRechnung 3.0 defaults

The export defaults ship pre-configured for the current XRechnung 3.0 standard. The Business Process Type and Specification Identifier are the two profile fields that identify the e-invoice standard against which each document is generated:

These defaults ensure generated documents declare conformance to XRechnung 3.0. Only change them if you are targeting a different profile and you understand the downstream validation impact.

E-invoice in email sending

When a document is sent through the Business Central email (the Email action on a posted document), the app completes the email. Two fields control the attachments:

The following applies:

If another extension renames the standard PDF so that the document number is missing from the file name, the app does not recognise it as the standard PDF. It then stays in the email next to the ZUGFeRD PDF.

Document attachments in the e-invoice

With Add Document Attachments to eInvoice switched on, the attachments of the posted document are embedded in the e-invoice as supporting documents - each with its content, its MIME code and its file name including the extension. The field is off by default, because everything embedded goes to the customer: switch it on only if all attachments of your posted documents may be passed on.

eInvoice Compliance Check

Here you will find the settings for the compliance check.

image-1749194964361.png

Document Queue

Here you can specify how long the entries are to be kept.

image-1749194979666.png

Expert Settings

The Show Expert Settings toggle hides advanced, low-level configuration by default. It is a UI-only switch (it is not stored in the setup). When you enable it, the following additional groups become visible on the setup page:

Leave Expert Settings switched off during normal operation. These groups define how documents are built and validated - incorrect changes can cause generation or validation to fail.

The behaviour of individual compliance rules (enable/disable, severity override, category and stage) is configured separately - see the Rule Setup page.

Configuration & Administration

Customer and Vendor Setup

Customer-Specific Settings

Access via DEXPRO eInvoice Setup → Customer Setup

Configuration Options:

Vendor-Specific Settings

Similar configuration available for vendors for purchase credit memos.

Email Templates

The system uses Word-based email templates:

Available Templates:

Template Features:

Configuration & Administration

OAuth 2.0 Setup

The OAuth 2.0 / Open Id users and their access tokens are managed here.

 

image-1729158448988.png

Configuration & Administration

VAT clauses and VATEX codes

When an invoice line is not taxed at the standard or a zero rate - an intra-community supply, a reverse-charge supply, a tax exemption - the e-invoice must state a VAT exemption reason for its VAT category: a text and a code from the EU VATEX code list. The text is the description of the VAT clause on the VAT posting setup. The Code of a VAT clause in Business Central (for example EU-19) is a free key and is never sent as the exemption reason code; instead, the app adds the field eInvoice VATEX Code to every VAT clause.

{add screenshot of VAT Clauses here}

Fields and actions on the VAT Clauses page

While the app is enabled, creating or editing a VAT clause fills in the detected code if the clause has no VATEX code yet. A VATEX code that is set on a clause is never overwritten - neither when you edit the clause nor by a later app version with a different detection.

The list offers the EU-wide VATEX codes that the KoSIT validator used by the Digivoice service accepts. National codes (VATEX-FR-..., VATEX-ES-...) and codes that were added to the code list only recently, such as VATEX-EU-144, VATEX-EU-146-1E or VATEX-EU-159, are not offered, because that validator would reject them.

How the code is detected

A clause code that is itself a VATEX code - VATEX-EU-IC, or EU-IC without the prefix - is taken as it is. Otherwise the app reads the code, Description and Description 2 of the clause and recognises the usual wording in German and English, common abbreviations, references to the UStG and the EU VAT Directive (for example § 4 Nr. 1b, § 6a or § 13b UStG, Art. 138, 146 or 194 of the VAT Directive) and the key terms in French, Italian, Dutch and Spanish. It detects:

Only exact patterns count. If nothing matches, or the wording fits more than one case (for example an "innergemeinschaftliche Lieferung" that also mentions "Reverse Charge"), no code is detected. Check the detected codes once and store them with Suggest VATEX Codes or set them manually; a stored code no longer depends on the detection.

VAT category of a VAT posting setup

The VAT category of an invoice line follows from its VAT posting setup:

VAT posting setupVAT category
VAT calculation type Reverse Charge VATK (intra-community supply) or AE (reverse charge) - see below
VAT calculation type Sales Tax with VAT % 0E (exempt)
Normal VAT or Full VAT with VAT % 0, marked as EU ServiceK (intra-community supply)
Normal VAT or Full VAT with VAT % 0Z (zero rate)
Normal VAT or Full VAT with a VAT % above 0S (standard rate)

Intra-community supply or reverse charge

Business Central posts an intra-community supply of goods and a reverse-charge supply alike with Reverse Charge VAT; only the VAT clause tells them apart. If the clause of the VAT posting setup maps to VATEX-EU-IC and the setup is not marked as EU Service, the e-invoice declares an intra-community supply (VAT category K). In every other case it declares reverse charge (VAT category AE); services to businesses in other EU countries (EU Service) are always reverse charge.

Which code the e-invoice sends

Without a VAT clause on the VAT posting setup, the app uses a generic exemption reason text for the category, for example Reverse charge or Intra-Community supply.

Validation

Rule VAL-VAT-005 reports, as a warning, VAT clauses that do not decide what they should. The e-invoice is still valid, but it may not say what you intend:

Two rules report missing data of an intra-community supply as errors, because KoSIT would reject the e-invoice:

The findings appear in the Live compliance check (FactBox) and in the Validation Findings; a VAL-VAT-005 finding about a clause leads to that VAT clause.

From Business Central 28.4 on, Microsoft's PEPPOL app adds a VATEX code field of its own to the VAT clause. The eInvoice Sender does not read it, so that the e-invoice does not depend on another app - always maintain eInvoice VATEX Code.

Application / Usage

Application / Usage

Working with Electronic Invoices

Sales Documents

Sales Orders and Invoices

Sales documents such as orders and invoices now have a fact box for the e-invoice conformity check. This informs the user of the following:

image-1749195675474.png

image-1749195697683.png

Common Missing Fields:

Posted Sales Invoices

In the Posted Sales Invoices list, you'll see:

New Fields:

New Actions:

{add screenshot of Posted Sales Invoice here}

Posted Sales Credit Memos

Similar functionality available in Posted Sales Credit Memos:

Service Invoices

Electronic invoicing is also available for Service Invoices with the same functionality.

Document Types and Formats

When downloading documents, you can choose from:

image-1749194324973.png

  1. XRechnung XML: Pure XML format compliant with German standards
  2. ZUGFeRD PDF: Hybrid PDF with embedded XML data
  3. XRechnung XML and Standard PDF: Both formats in a ZIP file

Sending Documents

Manual Sending

  1. Open any posted sales document
  2. Click Email, the standard Business Central action
  3. The app completes the email automatically:
    • Attaches the e-invoice in the format of the sending profile if Add eInvoice to Email Attachments is on
    • Uses the Override Contact Email as recipient and the CC Email Address as CC from the customer setup, if set
    • Marks the document as eInvoice Sent once the email has been sent, and closes the document's entries in the Document Queue that are still Pending, Error or Failed as Sent, so the background processing does not send the document a second time

Which attachments the app replaces and which always stay is described on the eInvoice Sender Setup page, section E-invoice in email sending.

Automatic Processing

The system can automatically process documents through the Document Queue:

Application / Usage

Document Management

Document Queue

Access via DEXPRO eInvoice Setup → Document Queue

image-1749195834907.png

Columns Displayed:

Actions Available:

Process Log

Monitor all system activities via DEXPRO eInvoice Setup → Process Log

image-1749195857339.png

Information Tracked:

FAQ

Here you will find questions and answers to various scenarios.

FAQ

Troubleshooting

Common Issues

Document Not Generating

Check:

  1. All required fields are completed (use the DEXPRO eInvoice Compliance Check FactBox)
  2. Customer has valid email address
  3. VAT setup is correct
  4. Connection to web service is working

Email Not Sending

Check:

  1. Email setup in Business Central
  2. Customer email address validity
  3. SMTP configuration
  4. Process log for error details

Validation Errors

Common causes:

Error Resolution

Process Log Analysis

  1. Open Process Log from setup page
  2. Filter by date range or document number
  3. Review error messages
  4. Check Context field for specific issues

Document Queue Management

  1. Open Document Queue
  2. Identify failed items (status indicators)
  3. Use Re-queue to retry processing of entries in status Error or Failed
  4. Check document data before reprocessing

Getting Help

Built-in Guidance

Support Resources

Best Practices

  1. Complete Setup First: Run guided setup completely before processing documents
  2. Test with Sample Data: Process test documents before going live
  3. Monitor Process Log: Regularly check for processing issues
  4. Maintain Customer Data: Keep email addresses and VAT numbers current
  5. Review Document Queue: Monitor automatic processing status

Document Status

The Document Status page (DXP eInv Document Status) shows the live processing state of every document that has been picked up by the eInvoice Sender. Each row is one queued document and reflects where that document currently stands in the sending pipeline, together with any error that occurred and where the finished e-invoice was sent.

{add screenshot of Document Status here}

Per-entry information

Status lifecycle

An entry moves through the following states as the pipeline processes it:

Validated and Generated are intermediate milestones within a single run. A healthy document typically progresses Pending → Processing → Validated → Generated → Sent.

Actions

A Failed entry is a dead-letter. Only content rejections of the last 30 days are picked up again on their own, and only once the document produces a different e-invoice; with automatic sending switched on, such an entry is then sent to the recipient in the same Job Queue run. Every other Failed entry stays put until someone fixes the cause and uses Re-queue.

Artifacts (GoBD audit history)

The Artifacts page (DXP eInv Artifacts) is the immutable audit history of every e-invoice the app has generated. Each row records one generated artifact together with the exact inputs, validation verdict and cryptographic hashes that prove what was produced and sent. The page is designed to satisfy German GoBD requirements for the traceable, unalterable retention of business documents.

{add screenshot of Artifacts here}

Fields

Immutability and GoBD relevance

Once an artifact reaches the Released state it becomes immutable - its content, hashes and verdict can no longer change. If a document has to be re-issued, a new artifact is created and the old one is marked with Superseded By, preserving the full chain rather than overwriting history.

The SHA-256 hashes of both the source payload and the generated artifact let you prove after the fact that a stored e-invoice is byte-for-byte the one that was validated and transmitted. Together with the validator config version and the milestone timestamps, this gives the complete, tamper-evident audit trail GoBD expects.

Actions

Validation Findings

The Validation Findings page (DXP eInv Validation Result) shows the read-only, persisted findings of the last validation run for a document. Whenever the pipeline (or the live compliance check) validates a document, every rule that reported something is stored here so it can be reviewed after the fact - you are looking at the recorded result, not running the validation again.

{add screenshot of Validation Findings here}

Fields

The stage a rule runs in (Source Data, Business Validation or Invoice Model) is configured on the Rule Setup page rather than shown as a column here.

Drilldown

Each finding can be drilled into to open the related record - the source document or the specific record that carries the offending value - so you can correct the data directly from the finding.

These findings are persisted from the last run. After you fix the data, re-run validation (or re-queue the document from the Document Status page) to refresh them.

Rule Setup

The Rule Setup page (DXP eInv Rule Setup) is where each individual compliance rule is configured. The app ships with a full rule catalog, and this page lets you tailor how each rule behaves - whether it runs, how severe its findings are, and how it is categorised - without touching the underlying implementation.

{add screenshot of Rule Setup here}

Per-rule configuration

The rule list is seeded automatically the first time the page is opened, so every catalog rule appears with its default settings ready to adjust.

The rule catalog

The catalog combines two kinds of rules:

Rules are spread across the three stages so problems surface as early as possible: SourceData checks the raw document data, BusinessValidation checks business-level constraints, and InvoiceModel checks the assembled invoice model just before generation.

Blocking-Mandatory rules

A subset of the official rules are Blocking-Mandatory: a violation of any of them is a guaranteed KoSIT rejection. These rules cannot simply be switched off. They are:

Setting Enabled to No on such a rule is not enough on its own - the rule stays effectively active until a compliance override is confirmed. Confirming the override stamps the user and the date/time on the rule row; clearing it removes that stamp and the rule becomes effectively active again.

This is a deliberate safeguard: turning off a blocking-mandatory rule produces documents that may fail KoSIT validation and may not be legally compliant, so the decision is recorded (who confirmed it and when) to keep it auditable. Do not disable these rules unless you fully understand the consequences.

KoSIT Report

The KoSIT Report viewer (DXP eInv KoSIT Report Viewer) displays the official KoSIT Pruefbericht (validation report) for a generated e-invoice directly inside Business Central.

What is KoSIT?

KoSIT (Koordinierungsstelle fuer IT-Standards) is the German public-sector body responsible for the XRechnung standard. It publishes the official validator that checks whether an e-invoice conforms to XRechnung. When the app pre-validates a document, it runs it against this official validator; the validator returns a Pruefbericht - the authoritative validation report describing exactly which rules passed and which failed.

The viewer

The KoSIT report is produced as an HTML document. The viewer renders that HTML in a WebPageViewer control so you can read the official report - with all its formatting, rule references and pass/fail detail - without leaving Business Central.

{add screenshot of KoSIT Report here}

Action

You can open the KoSIT report for an entry from the Document Status page or from the Artifacts page via Show KoSIT Report.

The sending pipeline and Job Queue

Every e-invoice the app produces is processed by a fixed, seven-stage pipeline. Documents are enqueued automatically when they are posted, and a recurring Job Queue entry works through the queue in the background. This page explains the stages, when documents are enqueued, and how retries and dead-lettering work.

The seven stages

Documents that are enqueued only to be attached to the posted document or e-mail (rather than auto-sent) stop after generation at status Generated - they are not transmitted in stage 7.

Stages 1-3 must all pass before generation. If any Error-severity finding is raised, the document does not proceed - review the Validation Findings and correct the data.

When are documents enqueued?

A document is enqueued automatically at posting time for the following document types:

The recurring Job Queue

Processing is driven by a recurring Job Queue entry:

On each run the Job Queue first re-checks recently rejected entries (see below), then picks up all Pending entries and the Error entries whose retry is due, and moves them through the pipeline. Each entry is processed in its own transaction, so an error in one entry does not undo or stop the others.

Retry, backoff and dead-lettering

If a stage fails with a recoverable error, the entry goes to Error and is retried on a rising backoff schedule with added jitter to avoid bunching:

Permanent errors and authentication failures do not wait for retries - they dead-letter immediately. A dead-lettered (Failed) entry is not retried on the backoff schedule; fix the cause and use Re-queue on the Document Status page (or, for several selected entries at once, on the document queue page) to reset the attempt counter and return it to Pending. The only exception is a recent content rejection, described below.

Corrected rejections are re-queued automatically

Before it processes the queue, every Job Queue run re-checks the Failed entries of the last 30 days that were rejected for their content - by the checks of stages 1-3 or by KoSIT. If the document now passes stages 1-3 and produces a different e-invoice than the rejected one, for example because the data was corrected, the entry goes back to Pending and is processed in the same run. An unchanged document is left as it is and costs no call to the Digivoice service.

Not re-queued automatically are entries that failed on an authentication error or on a permanent error reported by the Digivoice service, and rejections older than 30 days. Use Re-queue for these.

With automatic sending switched on, an entry re-queued this way is sent to the recipient without any further action. This also applies after an app update that changes the generated e-invoice: content rejections of the last 30 days are then generated again and, if they now pass, sent.

A document that is sent outside the queue with the standard Email action closes its Pending, Error and Failed entries as Sent, so the Job Queue does not send it a second time.

Live compliance check (FactBox)

The eInvoice Compliance Check FactBox gives you live e-invoice validation feedback while you are still editing an unposted document. It runs the same compliance rules the sending pipeline uses, so problems are caught before posting rather than after - when they are much cheaper to fix.

{add screenshot of Live compliance check (FactBox) here}

Where it appears

The FactBox is shown on unposted sales documents (quote, order, invoice, credit memo), service documents (order, invoice, credit memo) and the purchase credit memo. It re-evaluates as you change the document and displays the current per-document findings.

What it shows

Each finding can be drilled into to jump straight to the exact field that needs attention, so you do not have to hunt for the offending value.

Turning the check on or off

The live check is enabled by the master Enable Field Validation switch in the eInvoice setup, and then controlled per document area by three toggles:

Disable a toggle if you do not want the FactBox to evaluate documents in that area.

Block Posting on Validation Error

When Block Posting on Validation Error is enabled, the compliance findings are enforced at posting time, not just displayed. Each Error-severity finding is raised as a collectible ErrorInfo, so the user sees all blocking problems at once rather than one at a time. Every ErrorInfo carries two actions:

With Block Posting on Validation Error enabled, a document with any Error-severity finding cannot be posted until the findings are resolved. Warning and Information findings are shown but do not block posting.

Check of the posted document

The check above judges the unposted document, but the e-invoice is built from the posted one. With Block Posting on Validation Error enabled, the app therefore also checks the e-invoice the posting will actually produce: once the posted document exists, but before the posting is committed, it builds the e-invoice data from the posted document exactly as the sending pipeline does and runs the invoice-model rules - for example the BR-CO total rules and the VAT category rules. If an Error-severity finding remains, the whole posting is rolled back and nothing is posted. The user sees Posting stopped: the e-invoice would be rejected with the rule id and text of each finding and the action Open eInvoice Setup. If the e-invoice data cannot be built from the posted document at all, the posting is rolled back as well and the message states the reason.

Block Posting on Validation Error is off by default. With the default settings every posted invoice and credit memo produces an e-invoice, consumer invoices included. Before you switch the option on, make sure that only documents for actual e-invoice recipients produce one - this is controlled by Automatically Send Documents (eInvoice setup and customer/vendor setup) and Add eInvoice to Document Attachments.

Payment method and unit of measure mapping

An e-invoice has to express payment details and quantities using standardised, internationally recognised codes rather than the free-text values used inside Business Central. This page describes the two mapping lists that perform that translation, plus the routing field that identifies the recipient.

Payment Method mapping

Each Business Central Payment Method is mapped to an eInvoice Payment Type (the standardised payment-means code required by the e-invoice format). When a document is exported, the app looks up the document's payment method and writes the mapped payment type into the e-invoice.

{add screenshot of Payment method and unit of measure mapping here}

Two payment types need more than the mapping. Card Payment cannot be used for e-invoice recipients: XRechnung then requires the last digits of the card number, which Business Central does not store, so the compliance check reports an error - map such payment methods to another payment type, or use a different payment method for e-invoice recipients. Direct Debit needs a direct debit mandate on the document whose customer bank account has an IBAN or bank account number, and a SEPA creditor identifier: enter it as Creditor No. on the company bank account of the document (or on all company bank accounts, if you use only one creditor identifier).

The related Payment Term Keywords mapping list carries an Import Payment Methods action that deletes all rows of the list and re-creates them from the existing Business Central payment methods, detecting the payment type automatically where it can, so you only have to assign the payment type to the rows it could not detect rather than enter them by hand. The list also shows which rows are still unmapped.

Import Payment Methods deletes all rows of the list without asking for confirmation. Payment types you assigned by hand - including those set in the eInvoice Payment Type field on the Payment Methods page - and any other keywords are lost and replaced by the automatic detection. Check every row afterwards.

International UoM Codes

The International UoM Codes list maps Business Central units of measure to the internationally standardised unit-of-measure codes required in the e-invoice. Every quantity written to an e-invoice must reference one of these standard codes, so ensure the units of measure used on your invoiced items are represented here. On the standard Units of Measure page an Auto-Detect Standard Codes action helps assign the international code, and the International Standard Code field offers a lookup into this list.

E-Invoice Routing No.

The routing field is available on both the Customer and Vendor cards. It holds the recipient's routing identifier (for example the Leitweg-ID used by German public-sector recipients) that tells the receiving platform where to deliver the e-invoice. On the customer it is captioned E-Invoice Routing No.; on the vendor it is captioned Buyer Reference (E-Invoice Routing No.).

Complete these mappings before going live. A missing payment-type or UoM-code mapping, or a missing routing number, will surface as a compliance finding and can block generation or transmission.

Extensibility (developers)

The eInvoice Sender is built around a small set of AL interfaces so that partners and customers can extend it - add support for new document types, plug in a different reader, or add their own validation rules - without modifying the base app. This page is aimed at developers.

Interface 1 - DXP eInv Doc Exporter

Implement DXP eInv Doc Exporter to build the export payload for a given document type. It has a single method, CreateDocument(DocHeader: Variant): JsonObject - turning one kind of Business Central document into the JSON payload the pipeline serializes and sends to generation.

Implementations are bound through the extensible Export Document enum: add a value for your document type and point it at your implementing codeunit. The pipeline selects the exporter by resolving this enum, so registering a new exporter is a matter of extending it.

Interface 2 - DXP eInv Doc Reader V2

Implement DXP eInv Doc Reader V2 to provide a reader over the CIM (common information model) representation of a document - its ReadDocument method fills the CIM buffers (document, party, line, allowance/charge, payment, attachment) so rules and generation can consume the data uniformly.

The Export Document enum binds both interfaces: each enum value points at an exporter and a reader for that document type. When you add a new document type you provide both.

Interface 3 - DXP eInv IValidation Rule

Implement DXP eInv IValidation Rule to add validation rules. It has two methods: Evaluate (runs the check and appends findings) and GetMetadata (returns the rule's category, default severity, stage, description and fix hint - which is what seeds Rule Setup). A single codeunit can dispatch on the rule id and serve many rules, keeping within the object-ID budget.

Rules are bound through the extensible Validation Rule enum, which provides a dedicated CUSTOM extension point for customer- and partner-supplied rules. Add an enum value bound to your implementing codeunit, and the rule participates in validation like any built-in rule - it appears in Rule Setup where its Enabled flag, severity override and stage can be configured.

The OnCollectValidationRules event

The app publishes the OnCollectValidationRules integration event. Subscribe to it to register your rule implementations with the validation engine at runtime. This is the hook that lets an extending app contribute rules into the collection the pipeline and the live compliance check both use.

Together these three interfaces plus the integration event cover the main extension scenarios: new document type (Doc Exporter + Export Document enum), custom model reading (Doc Reader V2), and custom validation (IValidation Rule + Validation Rule enum, registered via OnCollectValidationRules).