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.

Management API:

• Uses unified error codes and messages, with typed result models for export, company, user, and fiscal endpoints.
• Export, company, user and fiscal endpoints return typed result models.
• On company updates, null fields no longer overwrite existing values, and change tracking records only actual changes.

Archive:

• The NEW Archive view now supports filtering and sorting for E-Invoice status.
• Added a guided step-by-step tour that highlights its key features.

Fixes

• EFR updates on macOS: Fixed a failure that stopped EFR 2.8.4 from updating on macOS, where the boot replacement step aborted with an error. Affected installations can now update normally.

What this means for our users?​

Management API: Integrations get consistent responses and clearer errors across export, company, user and fiscal endpoints. Partial company updates are safer: fields you omit stay as they are, and your change history shows real changes only.

Invoice settings: Child companies inherit the organisation's InvoicePerLocation setting automatically, so it no longer has to be set company by company.

France e-reporting now covers both B2C and cross-border B2B obligations

B2C is reported daily in aggregated form. efsta stages POS receipt data and runs a scheduled daily process that gathers the registered cash registers for each SIREN, aggregates totals by transaction date, and sends the consolidated transaction and payment reports.

B2B cross-border transactions are reported individually, at transaction level, rather than aggregated.

Both flows share the same operational controls: per-SIREN and per-date run records, duplicate protection, automatic retries, dedicated failure alerts, and automated retention processing.

What this means for our users?​

Daily B2C reporting: Finance teams can reconcile aggregated submissions at SIREN and date level instead of tracking reporting per receipt. Integration teams continue to supply receipt-level data as they do today; efsta stages and aggregates it for the daily transmission.

Cross-border B2B reporting: Transactions with customers outside France are reported individually, so each one can be traced end to end.

When something fails: Failures that need intervention are raised through dedicated monitoring rather than being discovered at the next reconciliation.

The Croatia, Slovenia, and Spain documentation now explains how to set the startup fiscal number (FN) directly in the EFR. The guidance covers POS migrations and EFR replacements, including continuing transaction numbering from the configured TN while retaining the existing TL/TT combination.

The Czechia documentation now clarifies that efsta is actively working on support for EET 2.0 fiscalization.

What this means for our users?​

Startup fiscal number: Integrators can follow the updated guidance to preserve sequential numbering when changing POS systems or replacing an EFR, without first transmitting the last number from the POS.

EET 2.0: Partners and merchants in Czechia have clearer information about the current implementation status, without implying that EET 2.0 support is already available.

EFR 2.12.0 improves fiscal-number continuity when replacing a cash register or switching POS systems. Croatia and Slovenia now provide a Last Fiscal Number setting (Profile.Attributes "Fiscal_Set_Last_FN") so numbering can continue from the previous value. Spain's Fiscal Number handling has been improved to ensure the last value is saved correctly and the TN counter continues as expected.

• Portugal: Fixed custom PDF layout rendering in Simple POS.
• Poland: Added a #DISCOUNT_INVOICE warning for discounts and surcharges on invoices, and fixed an issue where special characters in free-text fields could truncate the end of the line.
• Italy: Fixed NF handling for transactions triggering fiscal commands on the printer.
• Germany now generates gapless BON_ID values

What this means for our users?​

Numbering continuity - Integrators can preserve sequential fiscal numbering during register or POS replacement in Croatia and Slovenia via the Fiscal_Set_Last_FN attribute. Spanish Fiscal Number processing has been improved to save the last value correctly and keep the TN counter accurate.

Fiscal-printer safeguards - Polish receipts retain complete free text regardless of special characters used, risky invoice discounts and surcharges are clearly flagged via #DISCOUNT_INVOICE, and Italian non-fiscal (NF) documents no longer trigger fiscal commands on the printer.

We fixed an issue that prevented the e-Invoicing onboarding page from loading when opened directly through the /classic/e-invoicing-onboarding route.

What this means for our users?​

You can now access e-Invoicing onboarding reliably from bookmarks, shared links, or direct navigation without first opening another Portal page.

The E-Invoicing guide for France gained a new section on testing sending and receiving. The most efficient way is a single onboarded test company: there is no need for a second company or a real trading partner, as you can address a test invoice to yourself. The test company also needs its full e-invoicing configuration, same as the productive company.

• A new warning documents VATonPayment, which must be set to true / 1 when the company is liable for VAT on receipt of payment (TVA sur les encaissements), as otherwise no payment data is reported for B2C and cross-border B2B transactions. It is repeated in the France tab of the Quick Start Guide.

What this means for our users?​

• Testing - Integrators can validate the complete French flow, from outbox through delivery to inbox, without a second company or a real trading partner.
• Payment reporting - Companies liable for VAT on receipt of payment now know they have to set VATonPayment if they want their payments to be reported.

Fixed an issue in the new Archive view that could prevent e-invoice previews from loading and display a document preview error.

What this means for our users?​

Merchants and partners in Germany can now open and review e-invoice previews in the Archive without encountering this loading failure.