Lithuania i.SAF Requirements: Deadlines, Scope, Workflow

Lithuania i.SAF requirements are about recurring VAT invoice register reporting, not generic e-invoicing. In-scope VAT-registered taxpayers submit issued and received VAT invoice register data through the i.MAS system operated by the State Tax Inspectorate under the Ministry of Finance of the Republic of Lithuania, usually referred to as VMI. For legal entities, the standard pattern is calendar-month reporting by the 20th day of the following month. If no VAT invoices were issued or received in the period, the filing obligation still remains, so the business submits empty registers or a header-only XML file. Businesses can submit through direct portal entry, XML upload, or web service, and the same i.SAF data can support preliminary FR0600 and FR0564 declarations plus discrepancy review.

That opening summary matters because many English results blur three different topics together: Lithuania e-invoicing, i.SAF invoice registers, and i.SAF-T audit files. They are not the same workflow. This article focuses on i.SAF itself, the recurring invoice-register layer that finance teams need to prepare month after month.

The distinction from i.SAF-T should be clear from the start. i.SAF is the ongoing submission of issued and received VAT invoice register data. i.SAF-T is Lithuania's standard audit file framework and should not be treated as the same recurring register submission. If your team mixes those obligations together, deadlines, data preparation, and control design all become harder than they need to be.

Most teams grasp the headline rule quickly. The real work is collecting invoice data from issued invoices, supplier invoices, ERP exports, and document archives in a format that is consistent enough to validate before submission and before any FR0600 cross-checking starts.

---

Who Must Submit i.SAF, and Who Usually Does Not

The first control is scope. Lithuania's VAT invoice register regime is aimed at VAT-registered taxable persons that need to report issued and received VAT invoice data through i.SAF. If you are designing a Lithuania i.MAS i.SAF guide for your own team, the first question is not "How do we upload?" but "Does this entity actually sit inside the obligation?"

For legal entities, VMI's usual rule is straightforward: report the calendar month and submit by the 20th day of the following month. Natural persons and other taxpayers can follow the VAT period assigned to them, so teams should not assume every taxpayer runs on the same monthly cadence just because many companies do.

The main exclusion readers often miss is the small-business VAT scheme. A taxpayer using that scheme should not be dropped automatically into the same Lithuania VAT invoice register workflow as a standard VAT payer. The safer operational approach is to confirm the entity's VAT-registration basis and reporting period before building the recurring close checklist around i.SAF.

There is also a closing-period edge case. If a taxpayer is removed from the VAT register, the final i.SAF data is not ignored. VMI still expects the closing register submission within the final deadline window, so deregistration needs to be treated as a process change, not as a reason to stop reporting entirely.

A useful way to think about scope is this:

• First decide whether the entity is an in-scope VAT-registered taxpayer.
• Then confirm the reporting period that applies to that taxpayer.
• Then document any special status, such as the small-business scheme or VAT deregistration, before the monthly or periodic workflow is handed to AP or tax operations.

That sequence prevents a common failure: building a technically neat submission routine for the wrong entity population.

---

What Data Belongs in the Issued and Received VAT Invoice Registers

i.SAF works as two connected registers: one for issued VAT invoices and one for received VAT invoices. In practice, that means your team needs invoice-level data that can explain who the counterparty was, which document is being reported, when it was issued, how VAT was treated, and what value is being reported.

At an operational level, each register entry should preserve the invoice fields that drive tax reporting and later validation:

• Counterparty identity details, including the supplier or customer information your books rely on for VAT reporting
• Invoice number and issue date
• Supply or taxable-event date where relevant to the register logic
• Taxable amount before VAT
• VAT rate and VAT amount
• Total amount and any references needed to understand adjustments, credit notes, or corrections
• Consistent document identifiers so the reported row can be matched back to the source invoice

The exact field mapping may be entered directly in i.MAS, supplied in XML, or sent through a web-service flow, but the underlying requirement does not change. The issued and received VAT invoice registers still depend on clean invoice-level data.

This is where many compliance teams lose time. Supplier names may be spelled differently across invoices and ERP masters. Dates may arrive in mixed formats. Tax amounts may be rounded inconsistently. Credit notes may not carry the same reference style as the original invoice. None of those problems looks dramatic when you review a single PDF, but they become expensive once you are trying to submit a full reporting period or trace a mismatch in discrepancy review.

That is why the data-preparation layer matters as much as the filing layer. If your source invoices are inconsistent, the register will be inconsistent too. The mechanics described in invoice data capture processes that standardize supplier invoice fields are relevant here because i.SAF readiness starts with structured fields, not with the upload button.

---

Deadlines, Nil Periods, and Choosing Portal Entry, XML Upload, or Web Service

Most readers arrive at this topic because they need a deadline-safe workflow. The baseline rule for legal entities is the clearest one to remember: i.SAF data is commonly submitted for the calendar month by the 20th day of the following month. Other taxpayers follow the VAT period assigned to them, so the period logic still needs to be checked rather than assumed.

The nil-filing rule is just as important as the due date. No issued or received VAT invoices in the period does not mean no submission. VMI guidance still expects empty registers or a header-only XML file. That matters operationally because teams often build controls around "documents received" and forget that a quiet month still creates a compliance task.

From a workflow standpoint, the three submission paths fit different operating models:

• Direct portal entry works best when volume is low, corrections are limited, or the team is keying data manually inside i.MAS.
• XML upload fits businesses that prepare register data outside the portal and want a repeatable file-based process.
• Web service makes sense when the business has a stable integration pattern and wants repeated submissions from systems rather than manual handling.

The wrong choice is usually obvious in hindsight. Manual portal entry becomes slow when invoice counts rise. XML uploads become fragile if the source data is still being cleaned in spreadsheets at the last minute. Web-service projects create noise if the team has not settled the field mapping and exception logic first.

Cross-border teams should also avoid importing assumptions from other countries. A process that works for Romania's D406 SAF-T filing deadlines and data-readiness workflow does not automatically fit Lithuania's i.SAF requirements, because the cadence, file expectations, and register logic are different even when both regimes sit inside the broader world of digital tax reporting.

---

Why i.SAF Feeds FR0600, FR0564, and Discrepancy Reviews

The most useful operational point in Lithuania's i.SAF workflow is that the register data is not only collected for storage. VMI guidance links i.SAF to preliminary FR0600 and FR0564 outputs and to discrepancy review. That gives finance teams a concrete reason to care about data quality before submission, not only after a filing issue appears.

In practice, this means the invoice register becomes a control layer. Once the period's issued and received invoice data is in i.SAF, the business can use that data to order preliminary declarations and review mismatches. If the source invoices were classified badly, if dates were inconsistent, or if VAT treatment was coded incorrectly, those problems surface downstream in a way that is much harder to ignore.

That does not mean i.SAF replaces tax judgment. Preliminary FR0600 or FR0564 outputs are still working papers, not automatic truth. Teams still need to review missing lines, edge cases, adjustments, and anything that does not reconcile to the accounting records. The value of i.SAF is that it gives VMI and the taxpayer a structured comparison point.

This is also the right place to restate the i.SAF versus i.SAF-T distinction. i.SAF is the recurring register feed that supports invoice-based VAT checks. i.SAF-T sits in a different audit-file context. If your team collapses them into one bucket, you end up designing the wrong controls, using the wrong data extract, or escalating the wrong issue to ERP support.

The broader policy logic is not abstract. OECD's 2025 Economic Survey of Lithuania says that reducing Lithuania's VAT compliance gap to the average level in Estonia and Latvia would raise Lithuania's tax revenues by around 1% of GDP. i.SAF exists inside that push toward cleaner, more reviewable transaction data. The same principle appears in other regimes such as Poland's JPK reporting and GTU code classification rules, where coded digital tax reporting only works if the underlying transaction data is classified correctly.

For the reader, the practical conclusion is straightforward: i.SAF is not just a file you send. It is part of the logic VMI uses to compare invoice-register data with VAT reporting and spot mismatches early.

---

Building a Submission-Ready i.SAF Workflow

A workable monthly Lithuania i.SAF process usually looks like this:

1. Confirm whether the entity is in scope for i.SAF and what reporting period applies.
2. Gather the issued and received VAT invoice data for that period from ERP exports and source documents.
3. Standardize the fields that usually break downstream reporting, such as counterparty names, invoice numbers, dates, VAT amounts, references, and document types.
4. Resolve exceptions before submission, especially missing references, unusual VAT treatment, duplicate documents, or invoices that do not reconcile to the books.
5. Choose the submission route that matches the business's maturity level: portal entry, XML upload, or web service.
6. Review the resulting FR0600, FR0564, or discrepancy outputs as a control step rather than treating submission as the finish line.

Most failure points happen earlier than teams expect. They confuse i.SAF with wider Lithuania e-invoicing initiatives. They skip nil filings because no invoices moved that month. They build an XML or web-service project before the source data is stable. Or they discover only during discrepancy review that supplier names, tax amounts, or dates were never normalized consistently in the first place.

That is why upstream document preparation deserves attention. The workflow ideas in invoice data extraction for compliance-ready VAT reporting are relevant here because a reliable register starts with reliable invoice fields. If your invoices arrive as mixed PDF, JPG, and PNG files from different suppliers, tools such as Invoice Data Extraction can pull invoice header, tax, and line-item data into XLSX, CSV, or JSON outputs and preserve source file and page references for review. That can shorten the time spent cleaning source data before the team maps it into Lithuania's register logic. It does not replace i.MAS submission, XML design, or VAT analysis, but it can make the source-data step less fragile.

The best monthly control is not the fanciest submission method. It is the one where scope, source data, exception handling, and post-submission review all line up. When those pieces are stable, Lithuania i.SAF filing requirements stop feeling like scattered tax-tech instructions and become a manageable finance process.