E-invoices: separate parsing, validation and approval

Structured format versus PDF. An ordinary PDF does not automatically contain structured invoice data. Germany's Finance Ministry distinguishes electronic invoices in an appropriate structured format from other invoices, including simple PDFs. Rules for domestic B2B transactions have applied since 2025 with transitions and exceptions; assess the requirements for your particular case. BMF electronic invoice FAQ, checked on 26 September 2026.

What information is available. The technical question is what information is actually available. XML can be parsed directly. A hybrid format contains structured information and a visual representation. A scanned image needs recognition first. Treating all three identically discards useful structure and introduces avoidable extraction errors.

Conversion is a different task. Converting a PDF into an electronic invoice is a different task from reading an electronic invoice already received. Conversion requires the necessary information to be taken accurately from an unstructured source and placed into an appropriate format. An attractive rendered document does not establish technical or business correctness.

Austria describes structured electronic submission for invoices to the federal government. Requirements for that B2G process should be distinguished from general internal invoice intake. Austrian business portal: electronic invoices.

The Swiss Federal Finance Administration describes both structured datasets through service providers and PDF submission through designated channels for federal invoices. Swiss federal electronic invoice guidance. These differences already make a generic “DACH e-invoicing obligation” an inadequate implementation brief.

Germany, Austria and Switzerland describe electronic invoices differently in the sources cited here:

Record country, recipient type, agreed delivery channel and expected format as process context. Have the responsible specialist determine which rules apply. Technical components can be shared while legal and recipient-specific requirements remain distinct.

A multinational business may receive documents under several arrangements simultaneously. Route them using explicit context rather than assuming that the invoice language identifies the applicable rules. A German-language invoice can belong to any of the three markets.

Format and profile. A parser should recognise more than “XML”. It must identify the format and profile and select the applicable rule set. KoSIT publishes XRechnung validation configurations. FeRD publishes ZUGFeRD specifications and validation artefacts; its catalogue on the research date includes version 2.5.2 dated 4 August 2026. KoSIT validation configuration, FeRD publications.

Versions. A new publication does not mean every historic invoice must immediately be reassessed using the newest rules. Define supported profiles, the relationship between incoming versions and validation rules, and treatment of unknown versions. Record the artefacts used in the validation result.

Hybrid documents. For a hybrid document, preserve the received file and process its structured component deliberately. Its visual representation helps reviewers navigate. Differences between the displayed and structured information should create an explicit review case rather than disappear through choosing whichever value is convenient.

Renderer. Test the selected renderer as well as the parser. A reviewer needs to understand the same record that the integration will pass downstream. If the review interface omits important fields, apparently successful approval may be based on incomplete information.

Four checks answer different questions about an electronic invoice:

Keep outcomes separate. Keep these outcomes separate. A technical failure needs an understandable reason and location. A business discrepancy needs a task for purchasing or accounting. Calling every problem an “invalid invoice” makes correction harder.

Deterministic rules. Validation should apply deterministic rules reproducibly. A language model can explain an error in plain language, but should not independently override a failed rule. Nor should it invent missing required information and present it as if it appeared in the source.

Warning policy. Define which warnings block further processing and which can be reviewed under an agreed exception procedure. The decision belongs in a controlled policy, not in an improvised model response. Record the policy version alongside the decision when it matters for later reconstruction.

Internal representation. Map invoice number, issuer, recipient, date, currency, totals and required line items into a defined internal representation. Preserve the source of each value. Resolve destination references separately: the supplier name printed in the document is not yet an accounting supplier identifier.

Provenance of values. Distinguish information read directly, information calculated under an approved rule and assignments confirmed by a reviewer. This makes later diagnosis possible. For an incorrect cost centre, the team should be able to identify whether the cause was source content, master-data matching or a human decision.

Rounding and data types. Specify rounding and data types. Money should not change meaning through casual string conversion. Carry currency explicitly. Include multiple tax rates, discounts, charges and credit notes in tests where they occur in the intended process. Accounting determines the appropriate business calculation rules.

Lines and totals. Retain the relationship between lines and totals. A correct overall amount can conceal incorrectly mapped positions. If the downstream workflow requires cost-centre allocation by line, accepting only header totals does not meet the requirement.

The case. An invented business receives a technically readable structured invoice for 100 ordered units. The agreed unit price is EUR 10, giving EUR 1,000 for that line before other components. Only 80 units have been confirmed in goods receipt.

Parsing and matching. The parser reads the line without OCR. Technical validation produces no blocking format error. Purchase-order and receipt matching then identifies a 20-unit discrepancy. The workflow creates a purchasing task and keeps business approval open.

Resolution. The owner determines whether another delivery has not yet been recorded, the invoice arrived early or a correction is required. The decision is connected to the source. Approval follows only after the issue is resolved. XML validation has fulfilled its purpose without pretending to establish physical delivery.

Second test. A second test deliberately changes a total in the structured document. Rule validation should now produce a different reason. Distinguishing format or arithmetic failure from a real-world business discrepancy belongs in acceptance testing.

Third test. A third test submits the original again. The workflow should connect it to the existing case rather than creating a new payable item. These tests collectively cover reading, business controls and repeated delivery.

Suitable tasks. AI can summarise an accompanying message, suggest a responsible reviewer or draft a clarification request. It can also assist with attachment classification. Provide only the information needed for that particular task.

Example. For example, an accompanying email may state that a second delivery will follow next week. A model can surface that statement with its source. It should not convert the message into a confirmed goods receipt. Communication and an approved receipt record provide different kinds of evidence.

No unnecessary re-extraction. Avoid unnecessary re-extraction. If an amount exists in structured data, an additional visual model response should not silently replace it. A disagreement creates a review task. This rule keeps the workflow explainable and reduces avoidable model usage.

Explanations stay tied to validation. AI-generated explanations should remain tied to the actual validation output. An explanation can describe a missing reference, but it should not invent a likely reference or assure the reviewer that a warning is harmless without an approved rule.

Handle failures, repeats and acknowledged handoff

States. Maintain separate states for received, technically checked, business review open, approved and transferred. Count completion only when the destination acknowledges acceptance. If a response disappears after submission, the result is uncertain; blindly creating another record could produce a duplicate.

Traceability. Connect the internal identifier, original reference, format version, validation-rule version, errors, approval and destination identifier. Avoid copying complete document contents into routine diagnostic logs. Controlled references to the document store can provide business traceability without unnecessary duplication.

Unreadable inputs. Unknown formats, damaged files and encrypted inputs need a visible queue. Assign responsibility for contacting the sender and connecting corrected submissions to the original case. A replacement file should not silently inherit approval granted to different content.

Retry versus rejection. Separate retryable transport problems from business rejection. Waiting and resending may resolve temporary connectivity, but it will not fix an invalid supplier reference. The operator needs an actionable reason and a safe next step.

Turn validation output into actionable work

Understandable descriptions. Translate technical rule identifiers into understandable descriptions while retaining the original message for reproduction. Accounting needs the affected field, source and permitted next action. An explanation may clarify a rule but should not independently downgrade its severity.

Different owners. A missing recipient reference may require clarification with the sender or responsible team. An unsupported format version instead calls for operator review of parser and validator configuration. Both remain unresolved, but they have different owners. This assignment speeds up handling without pre-empting a business decision.

Failure outcome in acceptance. Include the complete failure outcome in acceptance. After an update, a blocking case must not silently become a warning that nobody sees. Compare error classes and resulting states as well as extracted values. A version change can alter behaviour while leaving the interface looking identical.

Supplier contact. Agree how suppliers are contacted. State the specific missing or conflicting information. Do not claim an invoice is legally ineffective when the workflow has only identified a technical processing problem. A useful message enables correction and accurately describes the review performed.

Assemble an acceptance set before launch

Cases. For each supported format, include normal and deliberately invalid examples. Add wrong recipient, missing reference, credit note, repeated delivery, conflicting representation, partial delivery and interrupted transfer. Choose cases from your business; a single sample XML is insufficient.

Confirmation. The responsible specialist confirms the expected status and next owner for each case. Engineering demonstrates the rule version used and the result actually accepted by the destination. During a pilot, also reconcile intake with completed, intentionally excluded and unresolved cases, accounting for multiple files per transaction.

Result. The result is a workflow that uses structured data effectively while making difficult decisions visible. Prepare representative invoices, recipient requirements, destination details and the owners of business rules. Those inputs let you select and test parsing, validation and supplementary AI as clearly defined parts of one process.

These guides and service pages cover the decisions next to e-invoice processing:

• AI document processing: capture, review and transfer
• Automate invoice capture without hiding field errors
• Design an invoice approval workflow with clear ownership
• Plan a DATEV document workflow around the right transfer

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.