ZUGFeRD from existing M3 invoice data.
For defined OIS199 cases, RIOMA produces a PDF/A-3 with embedded ZUGFeRD/Factur-X data from the print XML. M3 does not have to produce its own e-invoice file. RIOMA is not a general e-invoicing platform.
What RIOMA supports
The shipped configuration produces ZUGFeRD for supported OIS199 invoices where both the issuer and the invoice address are in Germany. Suitable invoice data and a tax case the product can handle are required. The country pair alone does not guarantee a complete fit.
The visible PDF and the embedded structured invoice data come from the same M3 source. If mandatory information is missing, creation is rejected.
How the existing M3 data is used
- 01
Print XML
The source is the ordinary OIS199 print job, not a separately produced e-invoice.
- 02
Invoice model
A document-specific mapper fills the internal invoice model.
- 03
CII EN 16931
That model produces CII in the EN 16931 / COMFORT profile.
- 04
PDF/A-3
The CII XML is embedded in the PDF/A-3 (ZUGFeRD/Factur-X).
Prerequisites and limits
The points below are part of the current scope. They are not a footnote.
Limits of the output
- Several VAT rates are not yet carried into the CII output per line in full.
- XRechnung is not a shipped RIOMA function today.
- RIOMA does not send over the Peppol network. A UBL file is produced for the configured profile and uses the existing channels. That is not XRechnung.
- The Swiss QR payment part is a separate function and is not the same as ZUGFeRD.
Tax mapping
- The M3 tax code OBVTCD is read, but it is not yet fully mapped to EN 16931 categories and exemption reasons.
- The meaning of customer-specific tax codes, such as reverse charge or intra-community supply, has to be settled in the project.
Required data in the job
- Payment information has to be present in the source data or added in a suitable way. For ordinary German invoices it is not yet fully taken from the standard fields.
- If mandatory information is missing, RIOMA does not write an incomplete file.
