eInvoicing — Overview

This page describes how eInvoicing works across fiskaltrust markets from a PosCreator's perspective: the shared integration model that every market follows, and what changes from one market to the next. For a specific market, follow its country page (see Availability by market).

For the product-level concept — structured invoices, Peppol, eDelivery — see Delivery (/issue Endpoint). This page is the integration-focused companion to it.

One integration, many markets

eInvoicing is produced and delivered through the /sign and /issue calls your POS already uses — same account, same fiskaltrust.Middleware, same credentials. It is enabled by configuration per market, not by a new integration. Where a market is live via the API, the new behaviour is additive inside calls you already make. Producing a valid eInvoice is new behaviour enabled by configuration; fiscalizing a receipt does not by itself make it a valid eInvoice.

The shared model

Across markets, eInvoicing is layered onto the existing fiscalization flow through three endpoints you already have:

Element	Role in eInvoicing
/sign	Produces the structured eInvoice document (an EN 16931 profile, or a national schema) alongside the existing fiscalized receipt.
/issue	Optional. Registers the receipt (ReceiptRequest + ReceiptResponse) and delivers it to a recipient — a channel such as email/SMS, print, download, or a network.
/journal	Exports the operation data you sent, for audit and closings. It does not archive the eInvoice — revision-safe archiving is a separate concern.

The connection, authentication, and endpoint surface do not change — no new endpoints, request headers, or credentials.

Where the eInvoice data comes from

Every value in the eInvoice payload comes from one of three sources:

1. Sent by you to /sign — the ReceiptRequest.
2. Generated or calculated by the fiskaltrust.Middleware — for example the fiscal identifiers and the amounts derived from your charge and pay items.
3. Available in the fiskaltrust government service that processes the document — for example the merchant's master data from onboarding.

When /sign returns, the payload is final. It is transported to the network (Peppol, SDI, or another target) exactly as returned; nothing changes it afterwards. /issue only adds transport data on top of it, such as the recipient channel or a file name.

Status is polled, not pushed

The PosSystem API is request/response and idempotent. There is no status webhook in any market — you re-check delivery/clearance status by calling the issue endpoint again (GET /issue/{queueId}/{queueItemId}). The x-operation-id header is the idempotency key that makes retries safe (reused unchanged on a retry, it re-returns the original result instead of re-executing) — it is not itself a status channel. This is the one invariant across every market.

The integration flow

Where the API path is available, the flow is the same shape everywhere — your existing fiscalization flow with one added step:

Step	What happens
1. Sign	Call /sign as you do today. The response also carries the eInvoice document.
2. Issue for delivery (optional)	Register the receipt via /issue, then deliver it to a channel.
3. Poll for status	Applies when you used Step 2. Poll GET /issue/{queueId}/{queueItemId} until delivered / cleared. No webhook.

Invoices and invoice types

An invoice differs from a receipt in that it identifies the buyer: every invoice carries the buyer in cbCustomer. The invoice type is set by the receipt case of the /sign request alone; no cbCustomer field is needed for it:

Invoice type	ftReceiptCase (PosSystem API v2)
B2C invoice	0x2000_0000_1001
B2B invoice	0x2000_0000_1002
B2G invoice	0x2000_0000_1003

Table 1. Invoice types and their receipt cases.

For every invoice type, an eInvoice XML is generated, whatever the buyer's country, and validated semantically. If the validation fails, the /sign call fails. Which cbCustomer fields are required, for example CustomerVATId, depends on the situation, the market and the buyer. Fields that do not apply to the buyer can be left out or sent empty. For the full list of receipt cases, see ftReceiptCase.

What varies by market

The model is constant; the specifics are market-driven:

• Format — an EN 16931 profile (XRechnung, Factur-X/ZUGFeRD) or a national schema (FatturaPA, KSeF FA(3), ebInterface).
• Network / target — Peppol, a national clearance hub (SDI, KSeF), or a national portal.
• Regulatory model — post-audit (no clearance) vs. centralised clearance (the invoice is cleared before it is legally valid).
• Availability — some markets are live via the API, one runs through the Portal / InStore App, and one is a build in progress.
• Signatures & identifiers — e.g. a signature (the Italian FPA12 format) or routing identifiers (Leitweg-ID, CodiceDestinatario, KSeF number).

Exact case codes, delivery targets, and go-live status live on each country page.

Availability by market

Market	Regulatory model	Delivery path
Austria (AT)	B2G mandated; B2B optional	API — /sign + /issue via Peppol / the national portal
France (FR)	B2B, decentralised (PDP)	API — /sign + /issue via the Plateforme Agréée
Germany (DE)	B2B, post-audit	API — /sign + /issue via Peppol
Italy (IT)	B2G/B2B/B2C, centralised clearance	API — /sign + /issue via SDI. Supported: B2C and B2B, sending only — see What fiskaltrust supports.
Poland (PL)	B2B, centralised clearance	API (preview) — /sign + /issue via KSeF
EU (cross-border)	Voluntary — no national mandate	API — /sign + /issue via Peppol

Each market's Overview and Setup & testing pages live under its entry in Country-Specific Guides (in the sidebar).

Prerequisites (shared)

Requirement	Detail
fiskaltrust account + fiskaltrust.Middleware	An active account with a configured fiskaltrust.Middleware. See Portal registration.
CloudCashBox	eInvoicing is currently only available with a cloud-based fiskaltrust.Middleware (CloudCashBox), not with a local fiskaltrust.Middleware.
Existing fiscalization integration	Your POS already fiscalizes via /sign in the target market.
fiskaltrust.Middleware country configuration	Set to the market's locale — this drives the output format.
PosSystem API (v2)	eInvoicing is exposed through the PosSystem API (v2). If you don't integrate with it yet, start with the PosSystem API introduction.
Sandbox validation	Run one document end to end against a sandbox fiskaltrust.Middleware before the first live document.

Terminology

Term	Meaning
EN 16931	The European semantic standard the national eInvoice formats are profiles of.
Peppol	A network eInvoices can be delivered over; fiskaltrust holds the access point.
Receive mandate	The date from which a business must be able to accept an incoming eInvoice.
Issue mandate	The date from which a business must send its invoices as eInvoices.

Market-specific terms (XRechnung, ZUGFeRD, FatturaPA, XAdES, SDI, CodiceDestinatario, KSeF, Leitweg-ID, …) are defined on each country page.

Related pages

• Buyer data (cbCustomer) in eInvoicing — mapping of the cbCustomer fields to the EN 16931 buyer fields.
• Delivery (/issue Endpoint) — the product-level eInvoicing and eDelivery concept.
• Migrating from API v0 to PosSystem API (v2) — eInvoicing is a PosSystem API (v2) feature.
• Country pages — see Availability by market.

External references

• eInvoicing HUB (European Commission) — the EU Digital Building Blocks knowledge hub.
• eInvoicing Country Factsheets (European Commission) — regulatory factsheets per Member State and other countries.