Why do you need this change?
When receiving German e-invoices (ZUGFeRD and XRechnung), Business Central performs no content validation of the incoming document. The German format apps only check the technical envelope and then store whatever data is present ΓÇö missing mandatory fields result in empty fields with no feedback to the user.
This is a compliance problem:
-
EN 16931-1:2017 (the European e-invoicing standard mandated by Directive 2014/55/EU) does not only define fields, it defines a set of business rules with mandatory cardinalities ΓÇö e.g. invoice number (BT-1), issue date (BT-2), document currency (BT-5), seller name and VAT identifiers (BT-27 / BG-4), buyer name (BT-44), VAT breakdown (BG-23) and document totals (BT-112 / BT-115). A document is only a valid e-invoice if these mandatory elements are present. In Germany this is operationalised by the KoSIT / XRechnung Schematron validation rule set.
-
In Germany, § 14 UStG (as amended by the Wachstumschancengesetz, BGBl. 2024 I Nr. 108, 27.03.2024) introduced the mandatory ability to receive structured B2B e-invoices as of 01.01.2025. The BMF letter of 15.10.2024 ("Einführung der obligatorischen E-Rechnung") references EN 16931 and the XRechnung/ZUGFeRD profiles as the binding basis. Proper receipt implies the system can determine whether an incoming invoice is complete and EN 16931-conformant — not merely extract whatever data happens to be there.
Without mandatory-field/business-rule validation on import, invoices that are missing legally required content are silently accepted as if valid. This pushes the compliance risk (incorrect input VAT deduction, incomplete records) onto the receiving company and gives the user no indication that the received document is non-conformant.
Additionally (legal basis, same BMF letter): a ZUGFeRD/EN 16931 invoice may lawfully be transmitted as pure CII XML without a PDF wrapper. Such a document currently cannot be received at all (see below), which should also be addressed.
Describe the request
On the inbound path of the German e-document formats, validate received e-invoices against the EN 16931 mandatory fields and business rules (and the XRechnung/KoSIT rule set where applicable), and surface clear, itemised validation feedback on the E-Document instead of silently importing documents with missing data.
Current behaviour (code references, repo microsoft/ALAppExtensions):
ZUGFeRD importer ΓÇö Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al (Codeunit 13919)
- The only hard checks are:
- XML attachment present in the PDF — ParseBasicInfo, lines 47-48 → error "No invoice attachment found in the PDF file. Please check the PDF file."
- Document type code in a fixed list — lines 59-73 → error "Unsupported document type: %1".
- All actual invoice content (seller, buyer, VAT IDs, invoice number, dates, currency, amounts, tax breakdown, line items) is read via GetNodeByPath / Evaluate and mapped without any TestField, FieldError, Error or business-rule check. Missing elements simply produce empty fields.
XRechnung importer ΓÇö Apps/DE/EDocumentDE/app/src/XRechnung/ImportXRechnungDocument.Codeunit.al (Codeunit 13915)
- The only error raised in the whole importer is "Invalid XML file" when the root element cannot be found (GetDocumentType, line 100). No mandatory-field or business-rule validation is performed.
No validation is hooked in elsewhere either:
- The Check procedures of the format codeunits (ZUGFeRDFormat, XRechnungFormat, EDocPEPPOLBIS30DE) and EDocPEPPOLValidationDE contain the only real validation logic, but they run exclusively on the export/send path (processing phase "Release"). They are never invoked during receipt; the inbound flow only calls GetBasicInfoFromReceivedDocument → ParseBasicInfo and GetCompleteInfoFromReceivedDocument → ParseCompleteInfo.
- The German app only consumes mapping/lookup helpers from the framework (FindVendor, FindVendorByServiceParticipant, FindGLAccountForLine, FindVendorByNameAndAddress) ΓÇö these resolve master data, they do not validate the invoice content.
So the received document is effectively just parsed and stored; there is no point at which the German format apps verify that the EN 16931 mandatory fields are filled.
Requested improvements:
- Validate incoming e-invoices against the EN 16931 mandatory fields and business rules (and XRechnung/KoSIT rules). At minimum, verify presence of the core mandatory fields after parsing and report a clear, itemised error/warning to the user when something required is missing.
- Provide validation feedback on the E-Document instead of silently importing documents with empty fields.
- Allow receipt of a standalone CII XML (XML without a PDF wrapper), so EN 16931 / ZUGFeRD invoices delivered as pure XML — which are admissible under § 14 UStG / BMF 15.10.2024 — can be processed. Today the ZUGFeRD importer requires the CII XML to be embedded in a PDF (GetDocumentAttachmentStream, lines 47-48) and the XRechnung importer handles UBL syntax only, so no inbound path accepts a standalone CII document.
Affected version: 28.1
References:
Note: If Microsoft considers inbound EN 16931 validation to belong in the core E-Document framework (microsoft/BCApps) rather than in the country format apps, please re-route this issue accordingly ΓÇö the point is that today this validation happens nowhere for received German e-invoices.
Update:
The referenced objects do exist ΓÇö they are in this repository (microsoft/ALAppExtensions), not in microsoft/BusinessCentralApps. They belong to the German E-Document app (Apps/DE/EDocumentDE). Verified against branch main, commit b6bee5c.
Object IDs and file paths:
- Codeunit 13919 "Import ZUGFeRD Document"
Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al
- Codeunit 13915 "Import XRechnung Document"
Apps/DE/EDocumentDE/app/src/XRechnung/ImportXRechnungDocument.Codeunit.al
- Codeunit 13920 "ZUGFeRD Format"
Apps/DE/EDocumentDE/app/src/ZUGFeRD/ZUGFeRDFormat.Codeunit.al
- Codeunit 13914 "XRechnung Format"
Apps/DE/EDocumentDE/app/src/XRechnung/XRechnungFormat.Codeunit.al
- Codeunit 11035 "EDoc PEPPOL BIS 3.0 DE"
Apps/DE/EDocumentDE/app/src/PEPPOL/EDocPEPPOLBIS30DE.Codeunit.al
- Codeunit 13921 "EDoc PEPPOL Validation DE"
Apps/DE/EDocumentDE/app/src/PEPPOL/EDocPEPPOLValidationDE.Codeunit.al
Permalinks to the specific code (pinned to commit b6bee5c):
Clarification on scope: this is primarily a compliance/feature request, not only an extensibility request. The core point is that the inbound parsing procedures (ParseBasicInfo / ParseCompleteInfo in the two import codeunits) map the XML data without validating that the EN 16931 mandatory fields are present, and the existing Check procedures (in the Format / Validation codeunits above) run only on the export/send path (processing phase "Release"), never on receipt.
If Microsoft considers the inbound EN 16931 validation to belong in the core E-Document framework in microsoft/BCApps (namespace Microsoft.eServices.EDocument) rather than in these country format apps, please re-route accordingly ΓÇö but the affected country-specific import codeunits listed above are all in microsoft/ALAppExtensions.
Internal work item: AB#640416
Why do you need this change?
When receiving German e-invoices (ZUGFeRD and XRechnung), Business Central performs no content validation of the incoming document. The German format apps only check the technical envelope and then store whatever data is present ΓÇö missing mandatory fields result in empty fields with no feedback to the user.
This is a compliance problem:
EN 16931-1:2017 (the European e-invoicing standard mandated by Directive 2014/55/EU) does not only define fields, it defines a set of business rules with mandatory cardinalities ΓÇö e.g. invoice number (BT-1), issue date (BT-2), document currency (BT-5), seller name and VAT identifiers (BT-27 / BG-4), buyer name (BT-44), VAT breakdown (BG-23) and document totals (BT-112 / BT-115). A document is only a valid e-invoice if these mandatory elements are present. In Germany this is operationalised by the KoSIT / XRechnung Schematron validation rule set.
In Germany, § 14 UStG (as amended by the Wachstumschancengesetz, BGBl. 2024 I Nr. 108, 27.03.2024) introduced the mandatory ability to receive structured B2B e-invoices as of 01.01.2025. The BMF letter of 15.10.2024 ("Einführung der obligatorischen E-Rechnung") references EN 16931 and the XRechnung/ZUGFeRD profiles as the binding basis. Proper receipt implies the system can determine whether an incoming invoice is complete and EN 16931-conformant — not merely extract whatever data happens to be there.
Without mandatory-field/business-rule validation on import, invoices that are missing legally required content are silently accepted as if valid. This pushes the compliance risk (incorrect input VAT deduction, incomplete records) onto the receiving company and gives the user no indication that the received document is non-conformant.
Additionally (legal basis, same BMF letter): a ZUGFeRD/EN 16931 invoice may lawfully be transmitted as pure CII XML without a PDF wrapper. Such a document currently cannot be received at all (see below), which should also be addressed.
Describe the request
On the inbound path of the German e-document formats, validate received e-invoices against the EN 16931 mandatory fields and business rules (and the XRechnung/KoSIT rule set where applicable), and surface clear, itemised validation feedback on the E-Document instead of silently importing documents with missing data.
Current behaviour (code references, repo microsoft/ALAppExtensions):
ZUGFeRD importer ΓÇö Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al (Codeunit 13919)
XRechnung importer ΓÇö Apps/DE/EDocumentDE/app/src/XRechnung/ImportXRechnungDocument.Codeunit.al (Codeunit 13915)
No validation is hooked in elsewhere either:
So the received document is effectively just parsed and stored; there is no point at which the German format apps verify that the EN 16931 mandatory fields are filled.
Requested improvements:
Affected version: 28.1
References:
Note: If Microsoft considers inbound EN 16931 validation to belong in the core E-Document framework (microsoft/BCApps) rather than in the country format apps, please re-route this issue accordingly ΓÇö the point is that today this validation happens nowhere for received German e-invoices.
Update:
The referenced objects do exist ΓÇö they are in this repository (microsoft/ALAppExtensions), not in microsoft/BusinessCentralApps. They belong to the German E-Document app (Apps/DE/EDocumentDE). Verified against branch main, commit b6bee5c.
Object IDs and file paths:
Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al
Apps/DE/EDocumentDE/app/src/XRechnung/ImportXRechnungDocument.Codeunit.al
Apps/DE/EDocumentDE/app/src/ZUGFeRD/ZUGFeRDFormat.Codeunit.al
Apps/DE/EDocumentDE/app/src/XRechnung/XRechnungFormat.Codeunit.al
Apps/DE/EDocumentDE/app/src/PEPPOL/EDocPEPPOLBIS30DE.Codeunit.al
Apps/DE/EDocumentDE/app/src/PEPPOL/EDocPEPPOLValidationDE.Codeunit.al
Permalinks to the specific code (pinned to commit b6bee5c):
https://github.com/microsoft/ALAppExtensions/blob/b6bee5ca6/Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al#L47-L48
https://github.com/microsoft/ALAppExtensions/blob/b6bee5ca6/Apps/DE/EDocumentDE/app/src/ZUGFeRD/ImportZUGFeRDDocument.Codeunit.al#L59-L73
https://github.com/microsoft/ALAppExtensions/blob/b6bee5ca6/Apps/DE/EDocumentDE/app/src/XRechnung/ImportXRechnungDocument.Codeunit.al#L100
Clarification on scope: this is primarily a compliance/feature request, not only an extensibility request. The core point is that the inbound parsing procedures (ParseBasicInfo / ParseCompleteInfo in the two import codeunits) map the XML data without validating that the EN 16931 mandatory fields are present, and the existing Check procedures (in the Format / Validation codeunits above) run only on the export/send path (processing phase "Release"), never on receipt.
If Microsoft considers the inbound EN 16931 validation to belong in the core E-Document framework in microsoft/BCApps (namespace Microsoft.eServices.EDocument) rather than in these country format apps, please re-route accordingly ΓÇö but the affected country-specific import codeunits listed above are all in microsoft/ALAppExtensions.
Internal work item: AB#640416