# 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 and, when **Block Posting on Validation Error** is enabled, also during posting against the posted document, before the posting is committed (see [Live compliance check (FactBox)](https://docs.squeeze.one/books/einvoice-sender-for-microsoft-dynamics-365-bc-en-us/page/live-compliance-check-factbox)).
- **Description** - a human-readable description of what the rule checks.

<p class="callout info">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.</p>

## The rule catalog

The catalog combines two kinds of rules:

- **Official rules** - the standardised business rules from the EN 16931 / XRechnung specification: the **BR-CO** and **BR-DE** rules, general rules such as **BR-25**, **BR-32** and **BR-37**, and the rules of the individual VAT categories (**BR-S**, **BR-Z**, **BR-E**, **BR-AE**, **BR-IC**, **BR-G**, **BR-O**).
- **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**: a violation of any of them is a guaranteed KoSIT rejection. These rules cannot simply be switched off. They are:

- the **BR-CO** arithmetic identities that guarantee the invoice totals add up correctly (BR-CO-10 and BR-CO-13 to BR-CO-17);
- **BR-32** and **BR-37** - every document-level allowance and charge carries a VAT category;
- **BR-S-08**, **BR-Z-08**, **BR-E-08**, **BR-AE-08**, **BR-IC-08**, **BR-G-08** and **BR-O-08** - the taxable amount of each VAT category matches the lines, allowances and charges of that category;
- **BR-Z-01**, **BR-E-01**, **BR-AE-01**, **BR-IC-01**, **BR-G-01** and **BR-O-01** - a VAT category other than the standard rate appears in the VAT breakdown exactly once if a line, allowance or charge uses it, and not at all otherwise.

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.

<p class="callout warning">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.</p>