Nicely rendered does not mean importable
The visible PDF page reveals nothing about whether the import works. Decisive is the embedded XML — and that is where the stumbling blocks lurk.
Whoever only notices at posting that something is wrong has hit the most expensive moment. The check belongs before that.

Error 1: no XML embedded at all
It happens more often than you think: a supposed ZUGFeRD invoice is in truth a normal PDF without an embedded file. The import then finds no data to take over.
The quick test is the attachment bar in the PDF reader. If there is no factur-x.xml or zugferd-invoice.xml, it is not a real ZUGFeRD invoice.
Error 2: wrong or too-lean profile
If an XML is inside, the next question is the profile. MINIMUM or BASIC WL carry too little for a full posting. The import then pulls incomplete data — or aborts.
It should be at least profile EN 16931. Trusting the mere existence of an XML is not enough.
Error 3: damaged or inconsistent file
Sometimes the XML is there but structurally defective, truncated, or the totals do not match the visible page. Such files should be detected before they are posted — otherwise the posting is wrong although the import “worked”.
Precisely the silent variant — import succeeds, data is wrong — is dangerous because it only surfaces in the close.
Check before DATEV does
A short check order that catches most problems:
- Is an XML embedded at all?
- Does it carry at least profile EN 16931?
- Is the file structurally undamaged?
- Are the mandatory details complete?
- Do the totals in the XML match the visible page?