Improvements​

• Germany: Updated XRechnung notification emails now show the seller name as the sender. Replies go to the seller contact email. The sending address remains on efsta's domain.

What this means for our users?​

XRechnung emails: Recipients can see at a glance who the invoice is from and can reply directly to the seller.

New features​

• Germany: Added #INVALID warnings for line voids without a matching receipt position.
• Denmark: Added optional Base configuration field AdrNr for the house number, used in SAF-T exports and printed after Adr on receipts.
• Sweden/Spain: Release Android EFR for production

Improvements​

• Sweden: Improved line void validation to check RPN references first, otherwise matching article fields, with compatible tax and sufficient remaining amount and quantity. Unmatched voids now warn #INVALID Line void <PN> does not match ….

Fixes​

• Germany: Fixed data export from expired hardware TSEs.
• Germany: Fixed DataCenter TSE backups failing with TAR incomplete by unpacking zipped log exports. Empty exports are handled correctly, and failed partial exports are no longer processed or acknowledged as complete.
• Denmark: Fixed SAF-T street and house-number separation for long addresses, names starting with Æ/Ø/Å, and customer addresses.

What this means for our users?​

German line void warnings: Integrators can identify unmatched voids without the new check rejecting receipts.

Separate house numbers: Danish users can enter the street in Adr and the house number in AdrNr, including formats automatic splitting cannot recognise.

Swedish line void validation: Incorrect references and voids matching only unrelated lines now generate warnings rather than passing the check.

Expired TSE exports: Stored data can now be exported after the hardware TSE certificate expires.

DataCenter TSE backups: Zipped logs and exports with no logs no longer cause the documented format failure. Failed partial exports remain reported as failures.

Danish SAF-T addresses: Exported street names and house numbers are separated correctly in the affected address formats.

New features​

• Added Public API v2 endpoints to list, inspect and deactivate fiscal units, plus fiscal unit search. Fiscal unit listings include serial number, status, assigned EFR/register and last transaction date. Deactivation is reflected immediately in the Portal. Existing authentication and company-level access controls apply.

Fixes​

• Fixed TAXID_Invalid by validating register profile TaxIds against the location’s owner company.
• Italy and Poland: Fixed missing e-invoice status in the Archive.
• Poland: Corrected translations and date formats in the Archive Export view.
• France: Restored multi-select for sending invitation links in E-Invoicing Onboarding.

What this means for our users?​

Public API v2 lets partners retrieve TSE details, manage deactivation and search fiscal units through their integrations.

E-invoice statuses are now visible in the archive for Italy and Poland.

Polish bill archive translations and date formats now display correctly.

register profiles use the location’s owner company for tax ID validation, resolving the TAXID_Invalid error.

French e-invoicing onboarding lets you select multiple companies again.

New features​

• Italy and Poland: Added e-invoice PDF viewing and downloads, alongside other supported countries. A disclaimer clarifies that PDFs are previews, not original invoices.
• Added a Migration Pending label to the partner onboarding list during provider transfers.
• Added clear error messages in failed export details.

Improvements​

• Germany and France: Reworded the e-invoicing onboarding notice.
• Added quick date ranges to exports and limited overly long Archive searches.
• Added banners in legacy views linking to the new Archive and Exports views.
• Improved data loading in searches and exports.

Fixes​

• Fixed export cancellation and confirmation buttons, and enabled Start export once mandatory fields are complete.
• Fixed saving edited export names and editing canceled exports.

What this means for our users?​

PDF previews let you view and download a readable copy of an e-invoice without confusing it with the original.

Migration Pending helps partners identify companies awaiting a provider transfer without changing their existing onboarding status.

Export errors make it clearer why a failed export could not be completed.

Onboarding notices provide updated wording for Germany and France.

Date ranges make export periods easier to select and prompt you to narrow archive searches that exceed the limit.

Legacy banners help you find the new Archive and Exports views.

Data loading is faster and more consistent in searches and exports.

Export controls now respond correctly when starting, confirming or canceling an export.

Export editing correctly saves custom names and supports editing canceled exports.

Improvements​

• Belgium, France, Germany and Italy: Updated PDF previews with country- and format-specific visualization templates for XRechnung, Peppol BIS Billing 3.0 and FatturaPA, including French labels for France.
• Belgium, France, Germany, Italy and Poland: Added “This is a preview, not the original invoice” at the top of PDF previews and above the Portal Outbox preview. The disclaimer is English-only.
• France and Germany: Updated the Portal dashboard's onboarding notification texts.
• Redesigned correction emails, removing the efsta logo and adding company legal details, website and imprint links, and transactional notices. Questions are directed to your partner, and a notice warns against forwarding personal correction links.
• Germany: Redesigned B2B XRechnung emails to highlight the issuer. A “Sent by” block shows available issuer details and contact email from the invoice XML. Subjects now retain the invoice number and seller name, with VAT ID and issue date in the body.

What this means for our users?​

PDF previews use templates aligned with the relevant invoice formats, helping finance teams review invoice data.

Preview disclaimer clearly distinguishes the visualization from the original electronic invoice. Translations are not included in this release.

Onboarding notifications use revised French and German wording in the Portal dashboard.

Correction emails clarify why you received the message, whom to contact and why the correction link should not be shared.

XRechnung emails make the issuing company and its available contact details easier for recipients to identify.

New features​

• Austria: Added support for two new signing-card generations (GlobalTrust ACOS 4.1 and PrimeSign v2).
• Czech Republic: Released EET 2.0 with multi-purpose voucher top-ups and redemptions, delegated sales via OnBehalf.TaxId, and invoice payments using NFS=PAY.
• Promoted Android EFR from beta to production, with multiple countries installable together.

Improvements​

• Czech Republic: Updated reduced VAT rates and added the authority's transaction ID to the journal for receipt-level troubleshooting.
• Germany: Added optional invoice references, notes, due dates, cost centres and additional address lines to the e-invoicing adapter. E-invoicing requires Opera_EInv_Enabled per register.
• Germany: Added multi-step update support for fiscal connector version 5.1.0.
• Poland: Improved invoice-number handling using the Cloud's invoiceNumberUsed flag, retaining consumed numbers even when a transaction is rejected.

Fixes​

• Germany: Excluded foreign customers from e-invoicing. Folios without a recipient are fiscalized without an e-invoice and return a warning instead of failing recipient validation.
• Poland: Corrected intermediary-routed B2C invoices to print fiscally before sending, using the printer-assigned number. These invoices no longer undergo KSeF polling; delayed KSeF numbering alone no longer causes an offline status.
• France: Included the 0% VAT group in Z-report payloads and stopped recurring logs/events from audit logs created without a valid tax ID.
• Slovakia: Removed unexpected duplicate payment and rounding text lines.
• Belgium: Enabled POS-supplied session references through OperationId on SvcPoint and RSvcPoint, with text and length validation.

What this means for our users?​

Austrian signing cards: Merchants can use the newly supported card generations for receipt signing (GlobalTrust ACOS 4.1 and PrimeSign v2).

CZ EET 2.0: Integrators can report voucher activity, invoice settlements and sales for another taxpayer. Supply delegated taxpayer data as OnBehalf.TaxId; omit OnBehalf for ordinary sales.

Android EFR: Android deployments can use the production app and install multiple country modules together.

Czech reporting: Updated VAT grouping and journaled authority transaction IDs support reporting and troubleshooting.

German invoice data: Enable Opera_EInv_Enabled on each participating register and supply optional invoice details where available.

Fiscal connector updates: Multi-step update support accommodates the transition to version 5.1.0.

Polish invoice numbers: Consumed numbers are not reused after rejection. Cloud responses without the flag retain the previous handling.

German invoice eligibility: Foreign customers remain fiscalized without e-invoicing. Missing recipients produce a warning, not a deferred invoice for portal correction.

Polish B2C invoices: Printed invoices are sent after fiscal printing. Offline sending is retried without reprinting; other send errors become warnings. Receipt-based invoices and invoices without a printout retain their existing flow.

French reporting: Z-report payloads include zero-rated turnover, while invalid-tax-ID audit logs no longer generate recurring events.

Slovak receipt printing: Payment and rounding information is no longer duplicated unexpectedly.

Belgian session references: Supply OperationId to distinguish sessions at the same service point. Values must contain 1-600 characters after trimming.

New features​

• Germany: Added optional XRechnung mappings for project, contract, seller order, dispatch, originator, accounting, and invoice-note information on invoices and credit notes. Supported ESR inputs include ProjectReference, ContractDocumentReference, SellerOrderReference, Ctm.AccountingReference, and document-level Metadata. These details also appear in the invoice preview.

Improvements​

• Customer-correction emails now link to the new efsta.eu portal and include the standard efsta legal footer with website and imprint links.

Fixes​

• Paid-in-full cash documents no longer show an IBAN beside the cash payment in the preview, avoiding the impression that a bank transfer is still required. The seller’s bank details remain available in the footer.

What this means for our users?​

Optional XRechnung fields: Integration teams can provide additional order, project, contract, accounting, dispatch, originator, and invoice-note information through ESR. Blank values are ignored, and supported legacy project and contract field names remain accepted.

Correction emails: Recipients get working links to the current efsta portal and clearer legal information in every correction request.

Payment preview: Fully settled cash invoices and credit notes now present payment information more clearly without suggesting an outstanding bank transfer.

Fixes​

• Germany: Fixed automatic Z reports configured with Fiscal_Z when transactions without a transaction ID are created automatically. The open fiscal day is now retained correctly so the next day's automatic Z report can be generated.

What this means for our users?​

Automatic Z reports. German installations using Fiscal_Z no longer lose the tracked fiscal day during automatic transaction processing, preventing the next required automatic Z report from being skipped.

• Germany fiscal reports now compare calendar dates when determining the TSE commissioning date. TSE assignments made on the register activation date retain their correct date, and commissioning dates matching the current date are accepted as valid.
• France: Fixed missing integrity-check ZIP files in Journal archive downloads and resolved SHA256 hash differences between local and cloud exports. FR exports no longer include a README file link.
• Fixed portal configuration synchronization: Encrypted configurations caused an error.
• Improved the state description returned by the Cloud API purchase endpoint for location-based TSE purchases.

What this means for our users?​

TSE commissioning dates: German fiscal reports provide more accurate dates, including for TSEs assigned on the register activation date.

FR exports: Resolved SHA256 hash differences between local and cloud archive exports. The readme download was removed from the FR Journal archive export, as its instructions referred to verification files that are only available from the EFR.

Configuration synchronization: configurations containing encrypted content can be sent from the portal successfully.

Purchase API responses: Integrations receive a clearer state description for location-based TSE purchases.

Embedded Portal 2.0 pages now request scripts in parallel in Chrome and Edge instead of loading them sequentially. We removed a redundant Content Security Policy declaration that prevented browser preloading, while the same policy remains enforced through the response header. Updated assets are published as version 2.23.12, ensuring browsers retrieve the optimized files.

What this means for our users?​

Faster embedded Portal: Merchants and partners should see shorter load times when opening classic Portal pages, with the greatest benefit on high-latency connections. Security policy enforcement remains unchanged.

• Germany: On-premises German EFR installations can again issue an XRechnung from a journaled receipt. The document now follows the standard EFR registration and e-invoicing pipeline, while voids and refunds produce credit notes. The e-invoice configuration is now accessible from the XRechnung tab.
• Poland: Added KSeF_Status (ONLINE or OFFLINE), KSeF_Number, and KSeF QR-code values to TraC.Fis. Non-KSeF invoices using DO=noprint now receive an NI-<EFR>/<TL>/<TT>/<n> fiscal number, and the default TN print label now refers to a transaction rather than a receipt.
• Lithuania: Added the current EUR cash drawer balance to /control. Device balance reads available through GET /peri/print/state are now logged with register and printer identifiers.
• Portugal: Test mode now follows the Fiscal_test profile attribute without replacing the configured Tax ID. A crash affecting CM transactions with negative multi-purpose vouchers was also fixed.

What this means for our users?​

German e-invoicing: Merchants can create and deliver e-invoices from the local journal without an additional cloud register. Issued documents follow normal EFR numbering, registration, export, and Portal outbox processing.

Polish invoicing: POS integrations can distinguish confirmed online KSeF submissions from queued offline submissions and access the assigned number or QR values through the normal response. Unprinted non-KSeF invoices now retain a stable fiscal number across the journal and downstream exports.

Lithuanian drawer balance: Operators can view the latest balance in EFR, while integrations continue to retrieve it programmatically.

Portuguese fiscalization: Test and production selection is clearer and no longer changes the merchant Tax ID, while affected voucher transactions can be processed without the previous runtime error.

The Czech EET documentation now covers EET 2.0 onboarding, including registering business units in DIS+, obtaining and renewing certificates, installing them in EFR, and configuring the portal unit ID in Loc.LegalId. Guidance also documents supported identifier formats, retry and queue behavior, the configurable Fiscal_timeout minimum of 2,000 ms, required receipt fields, and network prerequisites for *.trzbyeet.gov.cz.

What this means for our users?​

EET 2.0 migration: Czech merchants and integrators can follow the updated guidance to prepare new DIS+ certificates, portal unit IDs, EFR profiles, firewall access, and receipt layouts before onboarding opens on 1 November 2026.

Sales continuity: Integrators can understand how unacknowledged sales are queued and retried, including after the 48-hour deadline, and monitor them through RetryQueued, .trac retry protocols, and journal entries.

EFR now supports the Czech EET 2.0 data interface v4.1, with the playground endpoint, certificate authorities, signed acknowledgements, POK codes, and updated fiscal message fields. Portal unit IDs of up to nine digits are read from Loc.LegalId, while taxpayer IDs accept 8 to 10 digits.

Sales without a response, including temporary error -1, are queued and retried with a fresh message ID and the repeat-submission flag. Fiscal_timeout remains configurable with a statutory minimum of 2,000 ms. EFR continues retrying after the 48-hour delivery deadline and records one RETRY_DEADLINE compliance event until the sale is acknowledged.

What this means for our users?​

EET 2.0 migration: Install a current certificate issued through DIS+, configure the portal unit ID in Loc.LegalId, and allow access to *.trzbyeet.gov.cz (playground environment). TLS 1.2 or newer is supported, and the existing certificate-expiry warning remains available for yearly renewals.

Sales continuity: Registers can complete sales while the authority is unreachable. Integrators can continue monitoring buffered transactions through RetryQueued, retry protocol .trac files, and the journal entry raised when delivery exceeds 48 hours.

We added machine-readable OpenAPI specifications for the EFR unified API, including examples within the definitions. The specification for /register now serves as the single source of truth for the business-case examples in the documentation, keeping the guidance aligned with the API definition.

What this means for our users?​

OpenAPI specifications: POS integrators and partners can use a structured API description and matching examples when implementing the unified API. Basing the business-case examples on the /register specification makes it easier to compare the documentation with the API contract and reduces ambiguity during integration.

French inbound invoice status updates are now validated before sending. Reasons and comments are supported only for REFUSED, DISPUTED, and SUSPENDED, with reason options filtered by status. A comment requires a valid reason and is sent only in the structured rejection detail, eliminating duplicate or silently lost comments. Invalid combinations return 400 with a stable error code.

• France: Added SIREN to the supplier and customer legal registration fields when no legal entity is returned, preventing “Siren not found” and CANNOT_COMPUTE_UNICITY_KEY errors.
• Belgium and Germany: Corrected UBL output so VAT IDs are no longer duplicated as legal registration identifiers. A legal entity is now created only when a name is available.
• UBL date handling now preserves ISO dates and timestamps without time-zone shifts, continues to support day offsets, and rejects impossible dates.

What this means for our users?​

French status decisions: Portal users see only valid reasons and comment fields. Integrations receive an actionable 400 response instead of sending unsupported data or losing comments.

French SIREN: Invoices can be identified correctly even when the source data does not provide a legal entity structure.

Legal registration identifiers: Belgian and German documents no longer confuse VAT and legal registration identifiers.

Invoice dates: Supplied ISO values remain unchanged, while invalid calendar dates continue to be rejected.

France:

• French processing with Fiscal_Rules=LNE now records augmented transaction line data, audit events 323 and 329, and grand totals (Tot) with every daily, monthly, and yearly closure. Multi-purpose vouchers at 0% are excluded from grand totals and accumulated in Tot.GTvou.
• Updated proofjou so monthly and yearly hash checks cover the recorded grand totals.
• Fixed the first closure opening a new month so it also closes the previous month. Year closures now retain VAT-rate buckets absent from the closing month, including after a month without turnover.
• Corrected monthly and yearly Total de la période values to include 0% turnover and use properly rounded currency amounts.

What this means for our users?​

LNE audit data. Transactions, audit events, vouchers, and closure records now provide more complete data for LNE compliance and fiscal audits.

Closure totals. Daily, monthly, and yearly reports remain consistent across month boundaries, zero-turnover periods, VAT-rate changes, and 0% sales.

Journal verification. Use the proofjou version supplied with EFR 2.13.0 when verifying journals created by this release.

France E-Invoicing:

• Bulk sending of magic links has been temporarily deactivated.
• The Generate/Send Magic Link flow for French e-invoicing now lets partners select and activate an available feature plan for an individual company before onboarding. The selected plan is stored for that company, while existing activations are protected from duplication.
• The E-Invoicing menu item is now shown whenever the organisation has at least one French company, regardless of whether the feature is enabled. Where access has not been granted, a view containing the feature description and preview is displayed.
• Improved SIREN searches so values containing spaces return the expected results.
• Fixed an issue where selecting Contact support for a row with an invalid SIREN could result in a blank page.

What this means for our users?​

Feature activation: Partners with access to French e-invoicing can choose the appropriate plan as part of onboarding, ensuring the selected company is activated and billed on that plan. Activation applies only to that company, without changing other companies in the organisation.

Bulk sending of magic links: is temporarily disabled. Partners can continue to select a single company, choose its plan, and send the magic link for that company only.

E-Invoicing menu: Users in organisations with French companies now see the E-Invoicing entry in the navigation even before the feature is activated. Selecting it without access shows the feature description and preview, making it clear how to request activation.

Contact support: Partners can request help from support regarding invalid-SIREN without leaving the current portal page.

SIREN search: Users no longer need to remove spaces from a SIREN before searching.

The Opera adapter now supports French B2B e-invoicing. It routes corporate folios using a valid SIREN or SIRET from Tax2No, with email as a fallback. The new eDoc_test attribute sends e-invoices to the relevant test platform while keeping the fiscal transaction signed and live.

• Opera: Added order references, guest names as invoice line notes, and Name2/Name3 profile lines. German e-invoices no longer duplicate VAT IDs as legal registration numbers, and a credit-note error was fixed.
• Simphony: Added the FiscalExtensibilityDataSTS save group with QRCodeData1, allowing third-party STS callers to receive the fiscal QR string. This requires Simphony 19.9 and Harmonized 24.9.1.0.
• Belgium: Fixed receipt labels and proforma disclaimers that ignored the configured Trm.Lang.
• Hungary and Slovakia: Fixed payouts being registered as positive amounts due to double negation.

Read more here: France e-invoicing

What this means for our users?​

French e-invoicing: Opera merchants can route corporate invoices using established buyer identifiers and test e-invoice delivery separately from fiscal training mode.

Opera invoice data: Recipients receive clearer allocation and guest information, while German party identifiers and credit notes are handled correctly.

STS QR access: External printing solutions can render the same fiscal QR code as Simphony without processing receipt print data.

Belgian receipt language: Fiscal labels now follow the terminal's configured language.

Payout signs: Drawer payouts in Hungary and Slovakia are recorded with the correct negative amount.

New archive exports now default to a validity period of 30 days. We also fixed issues in the export view and disabled email fields when revoking export access.

• France: Changed endpoints for database operations required by e-invoicing and long-running processing, including SIREN register lookups.
• The Release Notes page now redirects to the efsta documentation site.
• The settings menu now collapses correctly after navigation through the avatar menu.
• Bill Management now displays the missing external-link icon to indicate an external navigation happening.

What this means for our users?​

Archive exports. New exports start with a defined validity period, corrected export views improve usability, and email details cannot be changed while access is being revoked.

Release notes. Users are directed to the efsta documentation site for current release information.

Portal navigation. Menus close as expected after avatar navigation, and external navigation from Bill Management is clearly indicated.

For Spain, we fixed a defect introduced in EFR 2.12.0 that caused the EFR to throw SyntaxError: Identifier 'l' has already been declared on every request.

What this means for our users?​

Spanish request processing: POS integrators and merchants using the affected EFR 2.12.0 release should upgrade to EFR 2.12.1 so requests are no longer blocked by this syntax error.