50.5 Validation (Formal Check)
50.5.1 Overview ¶
Automatic X-Invoice Processor checks every e-invoice it reads against the official rule sets. This validation determines whether the invoice is formally correct - that is, whether the XML structure conforms to the schema and whether the business rules of the EN 16931 standard and of the respective specification (XRechnung, ZUGFeRD/Factur-X) are met. The check runs entirely locally on your computer. No data is transferred to an online service.
Validation is enabled by default and does not change processing: an invalid invoice still passes through the filter and the tasks as before. The result is available in addition - in the processing log, as a filter criterion, as a notification, as a validation report, and in placeholders.
What is checked
| Check |
Content |
| XML schema |
Structure of the file according to the XML schema of the syntax (UBL 2.1 or UN/CEFACT CII). Schema errors abort the further check. |
| EN 16931 business rules |
Rules of the European standard (identifiers BR-..., BR-CO-..., BR-S-..., etc.), e.g. totals checks, mandatory fields, code lists |
| Specification rules |
XRechnung 3.0: rules BR-DE-... of the KoSIT (e.g. routing ID, payment details). ZUGFeRD 2.x / Factur-X: profile rules (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) |
| PDF envelope (ZUGFeRD/Factur-X PDF only) |
Business rules for hybrid documents BR-HYBRID-02 to 15: PDF/A-3 identification, Factur-X schema in the XMP metadata, embedding and name of the XML file; plus a basic PDF/A check (see chapter 50.5.4). |
What is not checked: the invoice content (whether prices and services are correct), the tax assessment, signatures, and the complete PDF/A conformance of ZUGFeRD files (the program checks the PDF envelope in a basic check, see chapter 50.5.4). Validation does not replace a professional invoice review.
50.5.2 Results ¶
| Result |
Meaning |
| Valid |
Schema and all rules met, no findings |
| Valid with warnings |
No errors, but at least one warning (e.g. a recommendation of the standard that is not met) |
| Invalid |
At least one business rule is violated |
| Schema error |
The XML file does not conform to the schema; the rule check is skipped |
| Not checked |
No result is available - with the reason (see below) |
Reasons for "Not checked":
- Validation is switched off in the program options (see chapter 40.17).
- The file contains no XML invoice data (e.g. a plain PDF without an embedded e-invoice).
- The XML data is neither UBL nor CII (no known e-invoice format).
- ZUGFeRD 1.0: there are no current rule sets for this outdated version; the data is read but not checked.
- The time limit per file was exceeded, or the check failed technically (entry in the error log).
- The rule packages are missing from the program folder (subfolder
Validation); reinstalling the program fixes this.
Each finding consists of a severity (error, warning, or information), the rule (e.g. BR-DE-15), the rule text, and the location in the XML. The number of findings stored per file is limited (default 300, adjustable); the counters are not affected by this.
50.5.3 Which rule set applies ¶
The program selects the rule set based on the invoice's specification identifier (BT-24, "CustomizationID" or "GuidelineSpecifiedDocumentContextParameter"):
| Invoice |
Rule set |
| XRechnung 3.0 (UBL or CII) |
XML schema, EN 16931 and the KoSIT's XRechnung rules - the same scenario as in the KoSIT validator |
| ZUGFeRD 2.x / Factur-X (profile from the identifier) |
Profile schema and profile rules of Factur-X - as in the Mustang validator |
Plain EN 16931 invoice (identifier urn:cen.eu:en16931:2017) |
Factur-X rules in the EN 16931 profile (CII) or EN 16931 rules (UBL) |
| Other identifier (e.g. Peppol BIS, older XRechnung version) |
General EN 16931 rule set for the syntax; plus an information or a warning that no dedicated rule set exists |
Invoices with an older XRechnung version (e.g. 2.3) are checked against the current rule set. The warning AXP-VERSION points this out; individual findings may then stem from rules that did not yet exist in the older version.
The included rule packages with their date and license are shown on the Validation options page (see chapter 40.17.3). They are updated with program updates; the publishers release new versions about once or twice a year.
50.5.4 PDF envelope (PDF/A-3, embedding) ¶
A ZUGFeRD or Factur-X invoice consists of two parts: the XML file with the invoice data and the PDF file that wraps it. Since version 2.5 the program also checks this PDF envelope. The basis is the business rules for hybrid documents of the Factur-X specification 1.09.2 (identifiers BR-HYBRID-02 to BR-HYBRID-15).
| Check |
Rule |
Severity |
| The PDF file is identified as PDF/A-3 (or PDF/A-4f) |
BR-HYBRID-02 |
Error |
The XMP metadata declare the Factur-X extension schema (prefix fx, namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#) |
BR-HYBRID-03 to 05 |
Warning |
The properties fx:DocumentType, fx:ConformanceLevel, fx:DocumentFileName and fx:Version come from the code lists; the version is 1.0 (for the XRECHNUNG profile the XRechnung version) |
BR-HYBRID-06 to 10 |
Warning |
The data relationship of the embedded XML file (AFRelationship) matches the profile: Data for MINIMUM and BASIC WL, Alternative for XRECHNUNG, otherwise Alternative, Data or Source |
BR-HYBRID-11 |
Warning |
The XML file is embedded as an associated file (entry in the /AF array of the document catalog) |
BR-HYBRID-12 |
Error |
The embedded XML file is named factur-x.xml or xrechnung.xml (zugferd-invoice.xml from ZUGFeRD 2.0 only gives a warning) |
BR-HYBRID-13 |
Error |
File name and fx:DocumentFileName match; fx:ConformanceLevel matches the profile of the XML invoice |
BR-HYBRID-14, 15 |
Warning |
In addition there is a basic PDF/A check (identifiers AXP-PDFA-...): fonts embedded (from version 2.5.0 on also in annotations such as comments, stamps and redactions), files attached to file attachment annotations with a data relationship (AFRelationship, from version 2.5.0 on), no JavaScript or launch actions, no XFA form, no encryption, output intent present, title/author/subject/keywords in the Info dictionary as in the XMP metadata. These findings are warnings or notes. This is not a complete PDF/A conformance check (like veraPDF).
Only three findings make the invoice Invalid: no PDF/A-3 (BR-HYBRID-02), no embedding as an associated file (BR-HYBRID-12) and an invalid file name (BR-HYBRID-13). All other envelope rules count as warnings, even where the specification rates them as "Fatal". Reason: many common generators - including most of the official FeRD sample PDFs - omit the fx schema although the XML is fine.
The envelope result appears in the validation report as its own block PDF envelope (see chapter 50.5.6) and in the Validation report window as the line PDF envelope. The findings appear together with the XML findings in the log, in the Validation finding filter criterion, in the Excel report and in the notification; the location names the place in the PDF file (XMP, /Root/AF, /Root/Names/EmbeddedFiles). For XML files the block is omitted. The option Check PDF envelope (PDF/A-3, embedding) (see chapter 40.17) switches the check off; the block then reads "Not checked".
50.5.5 Where the result appears ¶
| Place |
Content |
| Log list (see chapter 6.3) |
Field group Validation with the result and the first findings; the tooltip shows all stored findings. The context menu entry Show validation report... opens the complete report. |
| Log filter and log search (see chapters 5.2 and 5.5) |
Fields Validation result and Finding (rule or text) |
| Profile filter (see chapter 30.11) |
Criteria Validation result and Finding - e.g. route invalid invoices to a clarification folder |
| Email notification (see chapter 40.6.6) |
Send message for invalid e-invoices: one message per file with the result, rule set, the first findings, and the HTML validation report as an attachment. Warnings do not trigger a message. |
| Save validation report task (see chapter 22) |
Stores the validation report as HTML and/or XML next to the invoice |
| Send file task (see chapter 17) |
Check mark Attach validation report (HTML) and fallback of the CSV recipient type to the address from the invoice - feedback to the invoice issuer (see the how-to "Notify issuers of invalid e-invoices") |
| Placeholders (see chapter 70.1) |
<ValidationStatus>, <ValidationErrorCount>, <ValidationWarningCount>, <ValidationRuleSet>, <ValidationSummary>, <ValidationFindings> - for file names, extracts, database fields, and messages; the list of findings mainly for messages to the invoice issuer |
| Result preview (see chapter 8.11) |
Line Validation with the result of the example invoice |
| Excel report (see chapter 80.3) |
Columns Validation and Findings as well as the Findings sheet |
| Validate invoice... button in the toolbar (see chapter 2.3) |
Check any file and show the report - independent of profiles and of the switch in the options |
50.5.6 The validation report ¶
The validation report documents the check in a traceable way. It contains:
- Program version and time of creation
- File, storage location, and the SHA-256 hash of the checked XML data - this later proves exactly which data was checked
- Invoice number, invoice date, seller, and amount
- Specification (BT-24), scenario, the rule sets used with their versions, the rule package, and the validation engine
- Result with the number of errors, warnings, and information findings
- All stored findings with severity, rule, text, and location
- For PDF files the block PDF envelope: envelope result, PDF version, PDF/A identification, Factur-X schema and fx properties, embedded invoice with data relationship, fonts, active content, output intent, encryption and Info/XMP comparison (see chapter 50.5.4)
The HTML format is intended for reading and printing, e.g. for passing it on to the supplier. The XML format suits archive and downstream systems. Keeping the validation report together with the invoice is recommended for bookkeeping.
Validation report of an XRechnung with result, key data, and findings
The Validation report window shows the same information inside the program. Save report... stores it as HTML or XML, Open in browser shows the HTML version, and Copy puts the report as text on the clipboard.
Language of the finding texts
The rule texts come from the official rule sets, where they are available in English only (only KoSIT's XRechnung rules are German). The German program therefore shows its own German translation with the English original text below it - in the report window, the HTML report, and the clipboard; the XML report always contains the original text and additionally the translation (element "Translation"). The original text is authoritative. It matches the wording that the KoSIT validator or the sender's validator returns. The English program shows the original texts; the option Show validation messages in their original wording (English) (chapter 40.17) is therefore only offered in the German program.
The location is shown without the rule set's namespace details, i.e. shortened. The HTML report shows the full form on mouse-over, the XML report always contains it.
50.5.7 Typical use cases ¶
- Safeguard incoming invoices: route invalid invoices to a clarification folder via a filter criterion and inform accounting by email - valid invoices continue unchanged.
- Proof for the invoice: with the Save validation report task, the report is stored for every invoice - complete documentation of the formal check.
- Check your own outgoing invoices: a profile on the outgoing folder checks every generated e-invoice before it reaches the customer.
- Clarify a single case: with the Validate invoice... button in the toolbar you check a file manually and send the report to the supplier.
A step-by-step guide is available in the how-to "Validate e-invoices and save validation reports".