Lithuania Public-Sector E-Invoicing: SABIS Guide

Supplier guide to Lithuania public-sector e-invoicing: SABIS, EN 16931, portal/API/Peppol routes, the 2024 transition, and the 2025 oral-contract rule.

Published
Updated
Reading Time
9 min
Topics:
Tax & ComplianceEUGovernmentLithuaniaSABISPeppolEN 16931public procurement e-invoicing

Lithuania public sector e-invoicing has been mandatory for public-procurement invoice flows since 2017, and the live platform is now SABIS rather than eSaskaita. For suppliers, the practical answer is straightforward: if you are billing a Lithuanian public-sector buyer in scope of the procurement workflow, the invoice needs to move electronically through SABIS, whether you submit it through the portal, an API-based integration, or Peppol. Lithuania follows EN 16931 for this process and does not apply a separate national CIUS on top of that European baseline.

That means the current rule is best understood as a B2G operating requirement, not a general B2B mandate across the whole economy. The legal backdrop comes from the EU public-sector e-invoicing framework under Directive 2014/55/EU, but suppliers do not need to memorize the directive to work out what to do next. The key operational questions are simpler: is the buyer a public-sector entity, are you in the public-procurement invoicing flow, and are you sending the invoice through an accepted SABIS route in a compliant structured format?

Those are the questions this guide answers. Instead of stopping at a country summary, it walks through the eSaskaita to SABIS transition, the accepted submission channels, the EN 16931 data standard, the narrower 2025 oral-contract rule, and the point many cross-border teams care about most: Lithuania still does not have a broad live B2B e-invoicing mandate.

What Changed When eSaskaita Moved to SABIS in 2024

The biggest source of confusion is that Lithuania's public-sector mandate did not suddenly appear in 2024. What changed was the platform layer. eSaskaita was the earlier environment many suppliers and finance teams recognized, and SABIS became the replacement platform for the same public-sector invoicing context. If your internal notes, ERP mappings, or supplier instructions still reference eSaskaita, that is now legacy terminology for an operational process that has moved on.

The transition followed a clear timetable. Lithuania began the migration on 1 July 2024, then treated 1 September 2024 as the point when SABIS became fully operational. In practice, that matters because supplier workflows, user access, routing guidance, and public instructions now point to SABIS rather than the old eSaskaita interface. It is more than a rename. The handoff changes where invoices are submitted and how teams should document their public-sector billing process going forward.

The scale of the old platform helps explain why the transition mattered. According to Lithuania's ministry update on the eSaskaita to SABIS transition, the former eSaskaita system had about 40,000 active users and processed nearly 150,000 electronic invoices per month on average before the switch. That is a large enough installed base that many suppliers, accountants, and public buyers still encounter older references in templates or process documents. When you see them, the practical read-across is simple: map those instructions to SABIS and confirm the current submission route with the public buyer or your integration team.

You may also see SABIS discussed alongside guidance from the National Centre for Shared Functions and the Lithuanian Ministry of the Economy and Innovation. For suppliers, the useful takeaway is not institutional complexity. It is that current public-sector invoice workflows should now be documented, tested, and communicated under the SABIS name.

How Suppliers Can Submit Invoices Through SABIS

SABIS is not limited to one submission method. Official guidance describes three main routes: the SABIS portal, API integration, and Peppol. That gives suppliers room to match the platform to the way they already run billing operations.

The portal is the most straightforward fit when invoice volume is lower or the process is still fairly manual. A supplier can enter or upload invoice data inside the state platform without building a deeper system connection first. For a small finance team, that can be enough to stay compliant while keeping the process visible.

An API-based route makes more sense when invoices are already being created in an ERP or finance system and the goal is to reduce rekeying. In that setup, the supplier's public procurement invoice API workflow becomes part of a wider controls process: generate the invoice in the source system, validate the structured fields, then pass the data into SABIS through the supported connection path. The benefit is less duplicate handling, not a different legal standard.

Peppol sits in the same practical category for many larger or cross-border teams. If you already exchange structured invoices through the Peppol network, Lithuania's SABIS model is easier to place because you are not being asked to learn a purely local, proprietary way of sending public-sector invoices. You still need the invoice content and routing details to be correct, but the broader interoperability model should feel familiar.

That is the real workflow distinction suppliers should keep in mind. The route can change, but the objective does not. Lithuania public procurement e-invoicing still depends on structured invoice exchange into the public-sector environment. Whether you use the portal for manual handling or a connected route for automation, you should be choosing the method that best fits your internal controls, invoice volume, and system maturity.

Which Invoice Standard Applies, and What Changed for Verbal Contracts in 2025

For the invoice content itself, Lithuania follows EN 16931 and does not add a national CIUS on top of that model for public-sector e-invoicing. That point matters because suppliers often worry that each country will require its own extra semantic layer or custom field logic. In Lithuania, the baseline question is simpler: is your structured invoice aligned with the European standard used for public buyers?

For many teams, the most recognizable operational expression of that baseline is Peppol BIS Billing 3.0. If your organization already works with EN 16931-style public-sector invoices elsewhere, Lithuania should feel closer to Finland's EN 16931, Peppol, and routing model than to a country that has built a heavily localized invoice data model. That does not remove the need to check routing and buyer details, but it does reduce format uncertainty.

It also helps to separate two questions that are often blurred together. EN 16931 defines the structured invoice model. SABIS is the operational environment through which the invoice is submitted in the Lithuanian public-sector workflow. A supplier can be clear on the standard and still miss a routing rule, or understand the platform name but send the wrong invoice structure. You need both pieces aligned.

The narrower 2025 change is the other detail worth calling out. Public Procurement Office guidance made clear that, from 1 January 2025, invoices related to public procurement carried out under verbal or oral contracts also need to be submitted through SABIS, regardless of the oral contract value. That is important, but it should not be overstated. It is not a blanket instruction for every invoice in Lithuania. It is a specific extension inside the public-procurement context, and teams should assess it exactly that way.

What Foreign Suppliers Should Watch, and What Lithuania Has Not Mandated Yet

Foreign suppliers usually care about two things: whether they can route a compliant invoice into the Lithuanian public sector without a local workaround, and whether Lithuania has already moved to a broader B2B e-invoicing obligation. The first answer is generally yes, provided your invoice and routing setup match the accepted public-sector workflow. The second answer is no, at least for now.

On interoperability, the practical lens is straightforward. If your organization can issue a compliant structured invoice and send it through a supported route such as Peppol or another accepted integration path, Lithuania's public-sector model is designed to work in a cross-border environment. You still need to confirm the buyer's details, the correct endpoint logic, and the internal controls around public procurement billing. But this is not a case where every foreign supplier must abandon existing structured invoice capabilities and start from scratch.

Where teams get tripped up is the wider policy conversation. Lithuania is part of the broader EU discussion around VAT in the Digital Age, or ViDA, and that future policy context matters for long-range planning. But it does not mean Lithuania already has a live general B2B or B2C e-invoicing mandate in force today. The European Commission still treats those broader mandates as non-mandatory in Lithuania. For current execution, treat the requirement as public-sector specific unless and until Lithuania formally expands it.

That distinction matters even more if you invoice public buyers in more than one jurisdiction. The goal may look similar across markets, but the operational path is always local. A team comparing Lithuania with Croatia's supplier route for public-sector e-invoices, for example, will see the same push toward structured electronic exchange, yet the timing, platforms, and procedural details still need to be checked country by country.

A Practical Checklist Before You Send a Lithuanian Public-Sector Invoice

If you are about to invoice a Lithuanian public buyer, run through this checklist before sending anything:

  1. Confirm scope. Make sure the buyer is a Lithuanian public-sector entity and that the invoice belongs in a public-procurement workflow rather than an ordinary private-sector transaction.
  2. Check the platform path. Use SABIS as the live submission environment, not older eSaskaita references left over in internal notes or archived supplier instructions.
  3. Choose the right route. Decide whether the invoice should go through the SABIS portal, an API-connected workflow, or Peppol based on your current billing setup.
  4. Validate the structure. Confirm the invoice data matches the EN 16931 baseline expected for Lithuanian public-sector e-invoicing.
  5. Review the oral-contract edge case. If the invoice relates to public procurement performed under a verbal or oral contract, apply the 1 January 2025 SABIS rule before assuming the invoice can follow an older exception path.
  6. Separate adjacent obligations. Do not confuse public-sector invoice submission with VAT reporting or other country-specific reporting duties such as Lithuania's i.SAF invoice register workflow.

The main compliance burden is not that Lithuania has made invoicing unusually opaque. It is that suppliers need to separate scope, platform, and invoice standard clearly. Once those three pieces are lined up, Lithuania SABIS e-invoicing becomes a defined operational process rather than a moving target.

About the author

DH

David Harding

Founder, Invoice Data Extraction

David Harding is the founder of Invoice Data Extraction and a software developer with experience building finance-related systems. He oversees the product and the site's editorial process, with a focus on practical invoice workflows, document automation, and software-specific processing guidance.

Editorial process

This page is reviewed as part of Invoice Data Extraction's editorial process.

If this page discusses tax, legal, or regulatory requirements, treat it as general information only and confirm current requirements with official guidance before acting. The updated date shown above is the latest editorial review date for this page.

Continue Reading

Invoice Data Extraction

Extract data from invoices and financial documents to structured spreadsheets. 50 free pages every month — no credit card required.

Try It Free