Start with a specific file
Always test an identifiable export. Record filename, export time and application version. If exports share a name, a checksum helps identify them. It proves file identity, not business correctness.
For the first test, use fictional details and a simple calculation that can be checked manually. This eases debugging. Do not upload real invoices to arbitrary public validation services without assessment.
Validation log template
| Check | Record | If results differ |
|---|---|---|
| Identify the file | Export, filename, checksum if needed | Identify the correct export again |
| Determine the format | Actual version and profile | Clarify specification or export configuration |
| Validate technically | Validation tool, rule version, report | Link the message to the relevant rule |
| Review content | Recipient, service, quantities, totals | Correct the source and draft substantively |
| Check receipt | Intended channel and actual response | Clarify recipient requirements |
Use validation deliberately
A suitable tool evaluates the file against specific rules, so record their version too. KoSIT documentation and format packages help select appropriate validation. For tax classification, this guide refers to the current German Federal Ministry of Finance FAQ.
A message may concern structure, a mandatory value or consistency between fields. Fix the cause in the responsible source, then export again. Manually changing XML alongside the original PDF can introduce contradictions in hybrid formats.
Additional comparisons for ZUGFeRD
Recipient
The visible document and XML must refer to the intended recipient. A populated field can still be factually wrong.
Items
Compare description, quantity, unit and price in both representations against the reviewed draft.
Totals
Check calculations and displayed totals. A visually polished PDF is not independent proof of correctness.
Link the validation result
Store the report with the exact export tested. Do not use an old report as evidence for a changed file.
Recipient acceptance is a separate step
A validated file can arrive through the wrong channel or miss additional recipient requirements. A sending log initially proves only that transmission step. Record actual receipt or processing feedback separately.
When accepting a software feature, look beyond the export button. Require a repeatable chain from draft to specific validation result. Your accounting team remains responsible for the tax assessment of the actual case.
From the guide to the sample project.
Try the steps in the OOKI demo: tasks, client view, time entries and invoice draft with fictional data. No login required.
Try the demo (DE)Further sources
- German Federal Ministry of Finance: e-invoicing FAQ ↗
Questions on formats, validation and transitional rules; check the current primary source for your case.
As of: - KoSIT / XStandards Einkauf: XRechnung FAQ ↗
Structured invoices, technical validation and responsibilities.
As of: