Factur-X combines a readable invoice with structured invoice data under a defined hybrid specification. An ordinary PDF created through a browser print dialog does not automatically contain that payload or satisfy its packaging and profile requirements. The same PDF extension can therefore describe files with very different capabilities.
The format-selection workflow asks what the actual recipient requires. The current creator provides printable output and may use the browser’s Save as PDF option. It does not implement Factur-X, embed invoice XML or validate a hybrid profile.
Identify the structured component
FNFE-MPE describes Factur-X as a hybrid invoice involving a readable PDF/A-3 representation and XML data. The structured component is intended for software processing. It is more than a screen image of the invoice or a collection of text extracted from the page.
A normal PDF can be perfectly readable while lacking a structured invoice payload. Software may still attempt extraction, but that is a separate interpretation process. Do not describe the document as Factur-X merely because an accounting package can read some text from it.
Likewise, attaching an arbitrary XML file does not establish a valid implementation. The payload needs the correct model and profile, and the package needs the required relationships and metadata. A recognised name in the attachment title cannot supply those rules.
Confirm the required profile
Factur-X has profiles with different data coverage. Ask the customer and implementing provider which profile and release are required. Do not assume a basic-looking example satisfies every destination because it belongs to the same format family.
Record the accepted profile and version alongside the recipient instruction. A software claim of hybrid PDF support is incomplete without the implemented scope. Request a representative fictional output and an explanation of its validation behaviour and known limitations.
If the required profile needs facts the source model lacks, collect them before export. A buyer identifier, service period or tax reason cannot be invented from a readable layout. A converter must report gaps rather than silently claim a completed profile.
Review the readable and structured views
Check that both representations describe the intended invoice. Names, references, line scope, currency and amounts should be compared against the same confirmed source record. Reviewing only the visible page leaves the structured data untested.
A fictional negative test can deliberately give the readable preview one invoice number and the structured payload another. The test is useful only if the final workflow detects or exposes the conflict. A technically openable PDF is not sufficient evidence that the representations agree.
FeRD’s ZUGFeRD material also emphasises the relationship between the readable and structured representations. Use the applicable release documentation for exact requirements rather than assuming two separate files with matching totals are automatically the intended hybrid package.
Understand the browser-print boundary
The current creator renders a document preview and invokes the browser’s print process. Paper size, margins and Save as PDF availability depend on that environment. It is not a dedicated PDF/A-3 packaging implementation.
No structured XML is embedded by the application. Downloading its separate JSON and printing a PDF does not create Factur-X. The JSON uses the creator’s own schema and has not been mapped into the hybrid format’s required payload.
The guide to PDF and XML purposes explains the broader presentation-versus-structure distinction. Keep that distinction clear when explaining the current tool to a customer: useful invoice preparation is not the same capability as a verified hybrid export.
Test the implemented final exporter
Use fictional data that represents the real kinds of lines, references, tax categories and payment information the workflow needs. Inspect the actual embedded structured data and the profile indicators, not only the rendered screenshot.
Ask which checks cover packaging, schema, business rules and readable/structured consistency. Keep the validation report tied to the exact file and configuration. A test for another profile or a previous revision does not establish the current output’s status.
Protect customer information during external testing. A PDF can carry more than the visible page, including attachments and metadata. Do not upload a real invoice to an unfamiliar checker simply because its first page appears harmless.
Choose the right final workflow
If the recipient requires Factur-X, use software that genuinely implements the requested profile and release. Preserve useful preparation data from the current creator, identify missing facts and review the mapped result before delivery.
Keep transmission separate from creation and validation. A successful hybrid export does not prove submission through a portal, receipt by the customer or acceptance of the transaction. Assign those tasks and retain the relevant evidence in the appropriate workflow.
For an ordinary readable invoice, the current print output may serve its intended presentation role if it meets the recipient’s actual needs. Label it accurately. Do not add a hybrid badge, rename the file or imply standards support that the app has not implemented and verified.
For an acceptance test, identify the readable invoice number, structured invoice number and declared profile separately in the review sheet. Require the final software provider to show where each is checked. This makes a hybrid claim assessable without relying on a logo or the fact that the file opens in a PDF reader.