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

• Enabled - switches the rule on or off.
• Severity Override - overrides the rule's default severity (Error, Warning or Information). Error findings block generation and transmission; Warning and Information do not.
• Category - the grouping the rule belongs to, used to organise the catalog.
• Stage - the stage the rule runs in: Source Data Validation, Business Validation or Invoice Model Validation. Source Data and Business Validation run live on unposted documents; Invoice Model runs in the sending pipeline.
• Description - a human-readable description of what the rule checks.

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:

• Official rules - the standardised BR-CO and BR-DE business rules from the EN 16931 / XRechnung specification.
• App-specific rules - additional VAL-* rules provided by the app to catch data problems earlier and more precisely.

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 - notably the BR-CO arithmetic identities that guarantee the invoice totals add up correctly. These rules cannot simply be switched off.

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 BR-CO arithmetic-identity 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.