44 posts tagged with "release"

What's new?​

• 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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

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.

What's new?​

The Swedish Parking of Receipts documentation now includes proforma transactions in the parking chain. New XML and JSON examples show how to send NFS="PROFORMA" with the latest ResumeFN, receive a signed fiscal number from the PF series, and use that number when continuing or finalizing the transaction. Related references and links in the business cases and ESR elements documentation have also been updated.

What this means for our users?​

POS integrators can now follow the complete Swedish flow from parking and re-parking through proforma and finalization. The examples clarify that a proforma keeps the transaction parked under its own fiscal number, and that every subsequent request must reference the fiscal number returned by the most recent step of the chain.

What's new?​

The new Archive provides a searchable, paginated list of documents across permitted organizations, companies, and locations. Users can sort results, preview documents without losing their list context, download individual PDFs, and open documents in a full-page viewer. Archive export lists now refresh after user actions while preserving filters, sorting, selection, and scroll position.

• France e-invoicing navigation now separates E-invoicing onboarding, E-invoicing inbox, and E-invoicing outbox. The inbox is available only when the organization feature is enabled and the user has an eligible French company.
• Improvements were made to the IOPOLE VAT regime, and logged-in users can now view and copy their user ID.
• Minor Portal 3.0 issues were also resolved.

What this means for our users?​

Archive - Authorized users can find and work with archived documents more efficiently while keeping their current search, sorting, and navigation context intact.

France e-invoicing - Onboarding, incoming invoices, and outgoing invoices are easier to distinguish, with access limited to eligible users and organizations.

Portal usability - User IDs are easier to retrieve for support or administration, alongside VAT regime improvements and general stability fixes.

What's new?​

Spain’s VERI*FACTU guidance now explains how to use the new VatRegime values for REDE and Simplificado, including unified API integration and practical examples.

Sweden’s FN format and receipt parking guidance now covers {RegId}:{Type}:{TL}/{TT}/{Z}-{Num} and complete SUSPEND chains. Each park, resume, re-park, and closing transaction receives its own FN, while ResumeFN references the most recent response. Earlier FN formats remain accepted in ESR.FN, ESR.ResumeFN, and ESR.RFN.

Sweden’s journal export guidance now details the SKVFS 2021:16 file contents, including receipts, article registration history, discounts, Z reports, and audit events. It also explains how article history is derived from POS position data.

What this means for our users?​

Spain VAT regimes - Integrators can implement REDE and Simplificado through the unified API using clearer instructions and examples.

Sweden receipt chain & export - Integrators can reliably track parked receipts through re-parking, finalization, abortion, or resumption on another terminal by passing the latest FN in ResumeFN. Users can better understand exported audit data.

What's new?​

EFR now supports Spain’s REDE (recargo de equivalencia) and Simplificado tax regimes for both TicketBAI and Verifactu. REDE transactions can include the surcharge alongside IVA, with separate base, IVA, and surcharge totals and the appropriate fiscal payload fields. Verifactu uses regime key 18 for REDE and 20 for Simplificado.

Belgian X/Z user reports now include payment and VAT totals per operator through ZOprA.ZPayA and ZOprA.ZTaxA. This applies to user X/Z reports and user data automatically merged into turnover reports.

Read more here: Spanish VAT Regimes

What this means for our users?​

Spanish tax regimes - Integrators can declare eligible Spanish IVA transactions under REDE or Simplificado. EFR applies the relevant fiscal treatment to new documents, supports mixed REDE and non-REDE sales, maps surcharges to their corresponding IVA rates, and includes them separately when signing and submitting records.

Belgian user reports - POS applications can print per-user totals broken down by payment method and VAT rate. Operators with no payments or taxable sales receive empty arrays, while user Z reports continue to reset the reporting period after completion.

What's new?​

This release improves log handling for German TSE exports, and for Portugal, documents containing "NFS":"PAY" no longer include an unwanted line. Training documents also no longer display the tax exemption reason as undefined.

What this means for our users?​

German TSE operations - Integrators benefit from more clear and reliable logging during cloud TSE backups.

Portuguese documents - Fiscal and training documents now produce cleaner, more accurate output, without the unwanted line or an undefined tax exemption reason.

What's new?​

Portal 3.0.1 is a maintenance release following the Portal 3.0 launch. It applies small fixes and refinements identified during the first days of the rollout, keeping the new portal experience smooth as everyone settles in. There are no functional changes — everything works the way it did the day 3.0 arrived, just a bit more polished.

What this means for our users?​

Nothing to do and nothing to relearn: the portal updates itself to the latest version automatically, and the early rough edges of a major release get smoothed out quickly rather than waiting for the next big update.

What's new?​

Portal 3.0 is the new home for everything you already do in the efsta portal — the same pages and workflows, now inside a cleaner, faster, more modern interface built on the new efsta design system. Nothing you use today goes away, and no action is needed on your side: you are moved over automatically.

Around the new foundation:

• The main menu is reorganized around how you actually work — Administration, Reports, Receipt Management, Monitoring, Store, Settings, and Help — with breadcrumbs so you always know where you are, and a sidebar you can pin open or let auto-hide.
• A guided tour welcomes first-time users and points out where everything lives.
• Contact details moved out of a pop-up onto a dedicated Contact page under Help.
• The portal now detects new versions and refreshes itself, so you are always on the latest release without stale-page glitches.

What this means for our users?​

You get a portal that feels current and is quicker to navigate — fewer clicks to the pages you need, which helps most in complex, multi-entity setups — with none of the risk of a big-bang redesign: every page you rely on is still there, unchanged, exactly where you expect it. And because 3.0 is a foundation, the improvements ahead will land in this same consistent experience.

What's new?​

The Swedish Skatteverket journal export now covers the full article-registration lifecycle — registering, changing, deleting, parking, and moving articles — and its output has been hardened against invalid data types. With that, the Swedish EFR officially leaves beta state.

Networking and configuration also got sturdier: outgoing HTTPS connections to the fiscal recorder are now reused via keep-alive instead of being re-established per request, SSL certificates are decoded and validated before they are stored (including password-protected certificates and the EFSTA_EFR_SSL_CERT / EFSTA_EFR_SSL_CERT_PASSWORD environment variables), and if a certificate cannot be loaded, the middleware now falls back to HTTP instead of starting without any server. A CORS preflight issue that broke browser requests is fixed, and log overflow protection is now speed-based, allowing larger log files for analysis.

Country-specific fixes round it off:

• Polish KSeF handling accepts the new E2/E3 tax groups without validation errors, and the seller address is now taken from the company level (which more closely reflects the meaning of these fields in the specs). New tax groups now also works in Z reports with POSNET printers.
• In Hungary, the ping command is disabled after a Z report to prevent needless timeouts; Portuguese PDF receipts no longer show duplicated 0% tax reason descriptions.

What this means for our users?​

Swedish merchants get a compliant, complete journal export without beta caveats. Everyone benefits from faster, more resilient connections, safer certificate handling, and fewer stuck transactions — less time chasing printer errors and retry queues, more receipts flowing.

What's new?​

The E-Invoicing guide for Poland gained a new section describing the KSeF VAT exemption tax groups E, E2, and E3.

• Sweden left beta — the Swedish country solution is now officially released.
• The EFR as HTTPS Server section was reworked: the HTTPS server certificate and the client CA certificate can now be uploaded via API, password-protected certificates are supported, and the server certificate can also be provided via an environment variable.

What this means for our users?​

• Poland — integrators handling VAT-exempt sales can look up exactly which exemption group to send for KSeF instead of deducing it from the schema.
• Sweden — the documentation no longer carries a beta disclaimer; what you read is the officially supported solution.
• HTTPS certificates — rolling out certificates to EFR installations no longer requires file-system access; the documented API upload covers server and client CA certificates, including password-protected ones.

What's new?​

The validation service no longer raises a warning when a position is sent without a quantity. The transaction ruleset defines that omitting the quantity means the default of 1, so these submissions are perfectly valid — the misleading warnings are gone from validation responses and are no longer stored.

In addition, a line-void processing error affecting the UBL-based countries (Belgium, Germany, France) was fixed. It was caught in an internal environment before any customer ran into it.

What this means for our users?​

Your integration can rely on the documented default quantity without generating warning noise in monitoring, and line voids in UBL countries process cleanly — one less validation quirk to explain and nothing to change on your side.

What's new?​

The Common Business Cases section gained a new entry: Register Creation. It describes how to create a subregister in Multi POS and Multi Company mode by sending a transaction with NF="CREATERN", including what to send and what to expect back.

What this means for our users?​

Integrators setting up multi-register environments no longer have to reverse-engineer register creation from support tickets — the flow is spelled out step by step in the guide, in the same format as every other business case.

What's new?​

Digital receipt layouts become dynamic. Layout sections can now be shown conditionally via formula — with comparison operators (EQ, NE, LT, GT, LE, GE), EXISTS, and AND/OR/NOT — so a section's visibility follows the receipt content, for example =EQ({ESR.DT},"INVOICE"). A new Line List section renders any receipt array line by line (positions, header, and footer lines), and conditional formatting applies a fixed style palette — bold, muted, alignment, and more — per section or per individual line. Rules that error out are simply skipped, so a broken formula never hides receipt content.

Together, a single layout now covers all document types — fiscal receipt, invoice, non-fiscal slips, returns, daily reports — instead of maintaining separate configurations. Existing SmartBill visibility settings are untouched, and the behavior was verified against 13 real POS document types.

What this means for our users?​

Maintaining one layout instead of one per document type cuts your configuration effort and keeps branding consistent across everything you hand to the customer. Conditional visibility and per-line styling let invoices, returns, and reports each look right — without duplicating layouts or touching what already works.

What's new?​

Companies can now order e-invoicing features directly in the portal, following the same flow already used for reporting obligations. If e-invoicing is enabled at your partner but not yet active for your company, the e-invoicing menu offers the available features in a dropdown — select one, confirm the purchase, and the feature is activated on the spot. If the feature is not available through your partner at all, the portal keeps pointing you to your POS or efsta partner for support.

A bug in the feature-ordering process that mislabeled bundle features has also been fixed.

What this means for our users?​

Activating e-invoicing no longer requires a support round-trip: what your partner has enabled, you can switch on yourself in a few clicks — and bundles now show up correctly while ordering.

What's new?​

The e-invoicing guide for France gained a new section on Legal Payment Mentions, describing the three mandatory notes every French B2B e-invoice must carry. In addition, the French test environment is now available and its usage is explained under Testing.

What this means for our users?​

Integrators preparing for the French e-invoicing mandate can verify their invoices carry the legally required payment mentions, and can run end-to-end tests against the documented test environment before going live.

What's new?​

The French outbound B2B e-invoicing flow is live: registered customers can submit domestic B2B e-invoices through efsta and the Iopole platform. Submissions carry the mandatory French invoice content, retries are protected against creating duplicate invoices, and every submission is logged with traceable identifiers — validation or technical failures surface as clear, user-facing outcomes instead of silent errors.

Around the core flow:

• The portal shows your French onboarding state explicitly — Registering until directory registration completes, then Registered — and invoice actions stay safely blocked until you are registered.
• A dedicated French test environment runs alongside production, so partners can complete onboarding and send end-to-end test invoices with test data fully isolated from production.
• The Peppol validation service now stays warm in all environments, eliminating cold-start delays on validation requests.

What this means for our users?​

France's e-invoicing mandate is approaching, and you can now build and verify your outbound flow end-to-end — in test mode, against the real API — before going live. Clear registration status means no guessing about when you can start billing, and duplicate protection means a retried submission never becomes two invoices at the tax platform.

What's new?​

The Cloud EFR documentation moved out of the Getting Started guide into a standalone page of its own under the EFR section, making the hosted middleware easier to find and reference. Along with the move, a new section on multi-company authentication with the Cloud EFR was added.

For Spain, the VERI*FACTU declaration of conformity link now points to the latest declaration, and all previous versions of the document are available in the same public folder.

What this means for our users?​

• Cloud EFR — everything about the hosted middleware, including how authentication works in multi-company setups, now lives on one dedicated page instead of being scattered through the getting-started material.
• Spain — integrators always reach the current declaration of conformity, with older versions still accessible when an audit asks for them.

What's new?​

Croatian fiscalization now signs XML messages and computes the ZKI security code with RSA and SHA256 instead of the outdated SHA1 algorithm. This resolves the FIS_ERR "invalid digital signature" rejections seen against the tax authority's test environment and aligns the middleware with the current signing requirements.

What this means for our users?​

If you operate in Croatia, receipts are signed with the algorithm the tax authority expects — no rejected fiscalization messages, no manual intervention, and you stay compliant as the SHA1 phase-out proceeds.

What's new?​

The restart schedule now accepts multiple daily times as a comma-separated list, for example 03:00,12:00,18:00 — each entry is validated, changes take effect immediately, and existing single-time configurations keep working exactly as before.

Input validation got stricter where it protects your data: transactions containing undefined entries in the position, payment, or tax arrays are now rejected immediately with a clear #INVALID error for all countries, instead of being processed with incomplete data. Test tax IDs are also handled properly across countries, so test registrations no longer consume real activations.

Several country-specific fixes ship alongside:

• Polish KSeF e-invoices now send the net unit price rounded to two decimals, as the schema requires.
• Belgian fiscal data modules that report timestamps with milliseconds are accepted.
• The German middleware reliably detects the Cryptovision TSE again.
• Spanish subclient and region configuration issues are resolved, and journals for France, Hungary, and Lithuania now include the fiscal sequence number.

What this means for our users?​

Multiple restart windows let you fit maintenance around shift patterns instead of a single nightly slot. The stricter validation surfaces integration mistakes at the door with an actionable error, rather than as corrupted receipts later — and the country fixes remove concrete blockers in Poland, Belgium, Germany, and Spain.

What's new?​

This release resolves three issues in the German Oracle Opera integration: registrations on multi-company (Cloud) middleware instances are no longer rejected with #RN_TAXID, Z-report requests containing only totals no longer time out after 45 seconds, and mixed-rate deposit folios keep the correct VAT rate per line instead of collapsing every line to the first line's rate.

For Spain, broken configuration validations are fixed, so changing provinces in the base data works again without errors.

What this means for our users?​

Hotels and chains running Opera against a multi-company setup can register and close their days without manual workarounds, and deposit folios settle with correct VAT — no corrections in the back office afterwards. Spanish operators can maintain their configuration without getting stuck on validation errors.

What's new?​

Merchants in Germany can now order DATEV fiscal services directly from a cash register in the Portal, through a service-offer process similar to ordering a TSE.

The Portal is also now available in Polish, providing an additional interface language for Polish-speaking users.

What this means for our users?​

DATEV service ordering: German merchants can initiate their DATEV service order from the relevant cash register in the Portal, bringing fiscal service orders into a familiar workflow.

Polish language: Polish-speaking merchants and partners can use the Portal in their preferred language for easier navigation and daily administration.

What's new?​

For France, fixed the JOU export so the generated jou.zip archive now includes the previously missing manifest.xml file.

What this means for our users?​

JOU export: Merchants and POS integrators now receive a complete export archive containing the expected manifest, removing the need to add manifest.xml manually.

What's new?​

Spain's Verifactu declaration has been updated to include a link to previous declarations.

Poland's VAT initialization has been corrected for both supported fiscal printer integrations. KSeF-only exemption rates E2 and E3 are now excluded from printer VAT setup, preventing #PRINTER_VAT E2 not found setting VAT rates now and repeated initialization errors after updating to EFR 2.9.0.

What this means for our users?​

Verifactu declarations: Integrators in Spain can now maintain the required link between updated declarations and their predecessors.

Polish fiscal printers: Merchants updating from EFR 2.9.0 should no longer encounter VAT initialization errors caused by KSeF-only exemption rates being sent to their fiscal printers.

What's new?​

Spain fiscalization is no longer marked beta. Verifactu now supports rectificative flows for full and partial refunds, insolvency, uncollectible debt, simplified invoices, and manually declared legacy invoices. Retry handling now verifies duplicate submissions for Verifactu and TicketBAI, including separate cancellation codes. Zero-total TicketBAI transactions with zero-priced or 0% tax items are now transmitted correctly, and Álava retries after 24 hours no longer cause an unnecessary warning.

• Belgium: Added cloud-hosted FDM endpoint support with bearer authentication configured through Sign_Cfg.
• Germany: Updated the FCC runtime installed and upgraded for supported TSE deployments to version 4.4.1.
• France: Changed the LNE fiscal-code label and fixed /repo uploads in multi-POS configurations when file content changes.
• Lithuania: Added the 12% tax group valid from 1 January 2026, moved missing-tax-group errors from startup to first use, fixed handling of a missing RFN, and removed the beta flag.
• Poland: Restored VAT-group discount handling and added E2 and E3 exemption groups, including KSeF legal-basis mapping and fiscal output as group E.
• Security: Extended deployment encryption to modules that were previously missing the directive.

What this means for our users?​

Spain: Integrators can deploy the fiscal workflow without the beta designation and handle more correction scenarios without duplicate submissions blocking the retry queue.

Belgium and Germany: Cloud POS deployments can reach remote FDMs using a bearer token, while German installations receive the required FCC update automatically.

France, Lithuania, and Poland: Country-specific fiscal output, tax configuration, repository uploads, and discount processing now better match current operational and regulatory requirements.

Security: On-premise packages apply encryption protection more consistently across middleware modules.

What's new?​

Custom report exports now correctly include the selected customer data and register number. Previously, this information was missing from exported reports.

What this means for our users?​

Complete custom exports: Reports now retain the relevant customer and register information, removing the need to add these missing details manually after export.

What's new?​

Transaction custom exports now include Method of Payment, Document Type, and Invoice Type, providing more context for exported transaction data.

• Downloaded e-invoice files now use the corresponding invoice number as their filename. Invalid filename characters are automatically replaced.
• Fixed issues affecting the saving of cloud configuration entries and preventing structural portal exports.

What this means for our users?​

Transaction custom exports: Merchants and partners can include additional payment and document classifications in downstream reporting and analysis.

E-invoice filenames: Downloaded files are easier to identify and associate with the correct invoice, even when invoice numbers contain characters that cannot be used in filenames.

Cloud configuration and structural exports: Configuration changes can be saved as expected, and structural portal exports are no longer blocked by the resolved issues.

What's new?​

EFR 2.8.8 adds HTTPS certificate uploads through /cer/ssl and /cer/ca, plus layout overrides using the lay query parameter on /register. Cloud-EFR token requests now accept TaxId, TL, and TT query parameters in any casing. Repository uploads no longer incorrectly return #RN_TT after applying changes.

• Austria: Corrected the 4.9% tax group assignment in signature payloads.
• Germany: Added support for second-generation hardware TSEs while retaining first-generation support.
• France: Allowed the FIS Code line to be omitted by setting Fis_Sec or Fis_Certification to none, case-insensitively, for both NF525 and LNE rules.
• Italy: Fixed /recorder/lastdh.
• Poland: Fixed PosA sorting, Z-report counter updates, previous operator names on non-fiscal printouts, dynamic-content centering, and KSeF QR printing up to 216 characters on supported firmware.
• Portugal: Provided API-key configuration for a test EFR.
• Slovakia: Prevented descriptions longer than 39 characters from printing twice.
• E-invoicing: B2C invoices are no longer submitted by the hospitality adapter, while B2B and B2G processing remains available. Error responses now provide more descriptive service messages.

What this means for our users?​

API and deployment: Integrators can manage HTTPS certificates through the EFR API, select print layouts directly on /register, use flexible query-parameter casing with Cloud-EFR authentication, and update repository content without misleading errors.

Country compliance: Merchants benefit from corrected fiscal mappings, reporting counters, receipt content, QR-code handling, and broader hardware support across the affected markets.

E-invoicing: B2C invoices avoid unsupported submission flows, while cashiers and support teams receive clearer error details for failed transactions.

What's new?​

EFR 2.8.7 improves German TSE exports. Cloud TSE transactions are now closed and exported during Z reports, preventing E_MAX_OPEN_TX_REACHED and E_STORAGE_FULL. DataCenter exports use the dedicated log export service, with smaller time windows used when an export returns too many records. Expiry-date handling was corrected, and exports remain available for supported hardware TSEs after certificate expiry.

• Browser POS: Corrected CORS preflight handling with an allowlist for requested headers.
• macOS: Improved installation so EFR can start without manually removing the quarantine attribute.
• Cloud-EFR: Added a configurable client limit. The default limit is 10,000 when unconfigured; 0 allows unlimited clients.
• Austria: Added tax group H at 4.9%, effective July 1, 2026, while retaining the existing 10% group.
• Czech Republic and Switzerland: Improved tax ID validation and error messages.
• France: Enabled the e-invoicing document module and fixed looping restarts.
• Croatia: Fixed message handling for void transactions.
• Poland: Added line voids on fiscal receipts, improved non-fiscal layouts, translations, warnings, printer compatibility, deposit handling, KSeF certificate handling, and receipt footer wording.
• Portugal: Added searchable TL and TT selectors when more than 15 entries are available.

What this means for our users?​

TSE exports: German operators get more resilient daily and historical exports, including expired supported TSEs and large export ranges.

Installation and integrations: Browser POS connections, macOS setup, restart behavior, and tax ID feedback are more predictable.

Country updates: Austrian POS and ERP systems must send tax group H for eligible basic foodstuffs from July 1, 2026. Polish, Croatian, French, and Portuguese workflows receive targeted fiscal and usability improvements.

Cloud capacity: Cloud-EFR operators can control client creation and prevent unbounded resource usage.