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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.