German Practice Management FHIR Profiles (R4) - Local Development build (v0.90.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Steuer-Compliance

Tax and invoice interoperability

This page documents the boundary between the official gematik Digital Patient Invoice (DiPag) contract and optional tax defaults maintained in a practice service catalog.

DiPag is the invoice contract

Praxis invoice exchange uses https://gematik.de/fhir/dipag/StructureDefinition/dipag-rechnung from de.gematik.dipag#1.0.8 directly. This IG does not define a local Invoice profile or a second net/gross convention.

The inherited DiPag contract covers, among other fields:

• mandatory Invoice.totalNet and Invoice.totalGross;
• invoice identifiers, date, subject, recipient, issuer, and participants;
• treatment type and specialty;
• payment terms, due date, and payment destination;
• corrections and application references;
• totals for invoice lines, external laboratory services, GOZ deductions, and other deductions or payer shares;
• line references to billed ChargeItem resources;
• explicit GOAE, GOAE-new, and GOZ billing semantics.

The authoritative source is the gematik DiPag repository.

Gross line amount and included tax

DiPag assigns the following meaning to line-level price components:

The tax amount is not added on top of the base amount. For a gross line of 120.00 EUR containing 19.16 EUR VAT:

Invoice.lineItem.priceComponent[BruttoBetrag].amount = 120.00 EUR
Invoice.lineItem.priceComponent[Steuern].amount = 19.16 EUR
Invoice.totalNet = 100.84 EUR
Invoice.totalGross = 120.00 EUR

DiPagTeilsumme on totalPriceComponent[SummeRechnungspositionen] can additionally carry the partial net sum, VAT percentage, and VAT amount for a position type.

The examples example-invoice-zahnaerzte-exempt, example-invoice-19percent, and example-invoice-kleinunternehmer demonstrate this convention.

ChargeItemDefinition catalog defaults

Tax classification can depend on the provider, purpose of a service, patient relationship, and other transaction context. A service catalog therefore cannot always determine the final classification.

This IG retains two optional, non-binding defaults on ChargeItemDefinition.propertyGroup.priceComponent:

• ext-tax-category, bound to TaxCategoryDE and the authoritative UNECE-5305 code system;
• ext-tax-exemption-reason, bound to UStBefreiungsgrundVS.

These extensions no longer have Invoice as a context. They are catalog input for the invoicing system, not a competing invoice payload contract. The invoicing system remains responsible for applying the actual transaction context before producing the DiPag totals and included-tax amounts.

The examples example-cid-bema-heilbehandlung, example-cid-igel-bleaching, and example-cid-eigenlabor-material demonstrate catalog defaults for exempt, standard-rate, and reduced-rate services.

Kleinunternehmerregelung

KleinunternehmerregelungExt remains available on PraxisOrganizationDE as practice master data. A DiPag-compatible invoice can carry the required human-readable notice in Invoice.note.

The former ext-ku-hinweis-pflicht Invoice flag and its local FHIRPath invariant were removed. They duplicated invoice semantics without establishing the legal status of the referenced issuing organization. The invoicing system must determine whether the notice is required and populate the invoice text.

EN 16931, ZUGFeRD, and XRechnung

TaxCategoryDE uses urn:un:unece:uncefact:codelist:standard:5305, the code system used for EN 16931 tax category mappings:

DiPag 1.0.8 represents invoice totals, partial sums, VAT percentages, and included VAT amounts, but it does not make the local EN 16931 category extensions part of the Invoice profile. Conversion to ZUGFeRD or XRechnung is a downstream accounting mapping and must combine the DiPag monetary data with the final tax classification determined by the invoicing system.

Out of scope

Input VAT apportionment under German tax law requires fiscal-year context and belongs in the accounting system. This IG also does not decide whether a particular service is taxable or exempt. Those decisions remain the responsibility of the practice, its invoicing system, and qualified tax advice.

This implementation guidance is technical documentation and does not constitute legal or tax advice.