E-invoicing and ZUGFeRD in Jupiter ERP

Under German VAT rules, an electronic invoice (E-Rechnung) is issued, transmitted, and received in a structured electronic format that can be processed electronically. The format must follow the European standard EN 16931 or an interoperable format the parties agree. A PDF without that structured data is treated as an “other invoice”, not as an e-invoice for the mandate.

Two names appear often in German practice. XRechnung is a pure XML invoice format used especially with public-sector recipients. ZUGFeRD (and the related Factur-X family) embeds the structured XML inside a PDF, so humans can read the page while machines read the XML. Both aim at EN 16931 compliance when the right profile is used.

Receiving and issuing follow different calendars. Domestic businesses have had to be able to receive structured invoices since 2025. Issuing is phased through transition rules. Deadlines depend on your situation. Confirm them with your tax advisor and the current Federal Ministry of Finance FAQ.

A plain PDF shows what a person sees. It does not give accounting systems a reliable field set for seller, buyer, lines, taxes, and payment means. ZUGFeRD attaches that dataset as XML inside the same file. Recipients can archive the human-readable PDF and still import the structure into their systems.

EN 16931 is the European semantic standard for the invoice content. ZUGFeRD 2.x profiles map that content into the embedded XML. When people say “ZUGFeRD EN 16931 profile”, they mean the structured part is intended to meet that European model, not a free-form PDF attachment.

With e-invoicing enabled, Jupiter ERP builds the PDF from your document data and embeds ZUGFeRD 2.x XML with the EN 16931 profile. You work in the usual invoice or credit note form. The system maps master data, lines, taxes, and references into the structured part. On invoices the seller IBAN is included as a payment mean in the XML. The visible PDF can also show a GiroCode for bank transfer.

You can enable e-invoicing per document or set it as the tenant default in document settings. Send the PDF by email from the panel with text templates and an activity log. Outbound you issue ZUGFeRD 2.x with the EN 16931 profile in the PDF and download XRechnung 3.0 for public authorities. Inbound you read ZUGFeRD and XRechnung as expense receipts.

Setup turns e-invoicing on by default for new accounts, including paths that stay on Free after the trial. Filing received e-invoices as expense receipts in the panel starts at Business. You can still inspect received files in the public e-invoice viewer without an account.

Technology does not replace process design. Agree who receives structured files, where they are stored, and how exceptions (wrong buyer reference, missing VAT ID, credit notes) are handled. Keep number ranges and master data clean; the XML only reflects what is already on the document.

Retention and immutability still follow German bookkeeping principles (GoBD). An e-invoice is still a business record. Period lock and audit logs help, but your internal rules and your tax advisor decide how periods are closed. For founders, the audience page summarises Free limits and ZUGFeRD in the PDF.

If a buyer portal rejects a file, capture the error text and the profile they expect before you change process or software. Many failures come from incomplete master data (buyer reference, VAT ID, IBAN) rather than from the PDF wrapper itself. Fix the document once, then re-export; do not invent a parallel manual XML track that drifts from the booked invoice.