Lithuania SAF-T Requirements: i.SAF-T Audit File Guide

Lithuania's SAF-T requirement, known locally as i.SAF-T, is a structured XML audit file that businesses must produce and submit to VMI (Valstybinė mokesčių inspekcija, the State Tax Inspectorate) on demand during tax audits. It is not a routine filing. Unlike the monthly i.SAF invoice-register submissions that most Lithuanian taxpayers already handle, i.SAF-T captures the full general ledger, including journal entries, customer and supplier master data, and detailed transaction records. The obligation applies to businesses whose prior-year net sales exceeded EUR 300,000, and the file is only produced when VMI formally requests it as part of an audit or data verification.

The i.SAF-T format is Lithuania's national adaptation of the OECD Standard Audit File for Tax, the international framework designed to give tax authorities a standardized way to consume accounting data electronically. Lithuania tailored the OECD schema to align with Lithuanian tax law, chart-of-accounts conventions, and VAT reporting requirements. Several other EU member states have taken a similar path, implementing their own SAF-T variants with country-specific modifications. Bulgaria's approach to SAF-T implementation, for example, follows a comparable pattern of adapting the OECD baseline to local regulatory needs.

i.SAF-T sits within i.MAS (Intelligent Tax Administration System), VMI's broader digital reporting architecture. i.MAS is not a single obligation but an umbrella framework encompassing multiple data streams:

i.SAF — monthly electronic invoice registers submitted on a recurring schedule
i.SAF-T — on-demand audit files covering the complete accounting ledger, produced only when VMI requests them
i.VAZ — electronic transport/waybill documents

The critical distinction for compliance planning is the on-demand nature of i.SAF-T. Your finance systems must be capable of generating a compliant i.SAF-T export at any point, covering whatever periods VMI specifies in its request. Readiness, not routine submission, is the operational challenge.

Who Must Comply: The EUR 300,000 Revenue Threshold

The scope of Lithuania's i.SAF-T obligation is defined by a single, clear-cut criterion: prior-year net sales revenue exceeding EUR 300,000. If your business crossed that line in the preceding financial year, you are subject to the i.SAF-T requirement for the current period's data. This threshold formed the basis for expanding the obligation beyond invoice-level reporting to full accounting-document data, effective for financial periods beginning 1 January 2019.

The calculation is straightforward but worth stating precisely. The VMI looks at your net sales (revenue) for the completed prior financial year. A company that reports EUR 280,000 in net sales for 2024 would not be in scope for 2025. If that same company reports EUR 320,000 for 2025, it falls within scope for 2026 onward. The assessment resets annually, meaning businesses can move in and out of scope as their revenue fluctuates around the Lithuania SAF-T threshold.

Who is covered: The obligation applies broadly across entity types. Lithuanian corporate taxpayers (UAB, AB, and other legal forms) and individual entrepreneurs alike fall within scope once they exceed the revenue threshold. There is no exemption based on industry sector or business activity type.

What data falls within scope: i.SAF-T is not limited to invoice records, and it is not an expanded version of i.SAF invoice data. It is a fundamentally different dataset drawn from your accounting system, covering:

General ledger journal entries and chart of accounts structure
Customer and supplier master data (names, tax identification numbers, addresses)
Accounting source documents such as purchase and sales transactions
Tax-relevant transaction records tied to VAT and corporate income tax reporting

All of this must be producible in a structured XML format conforming to the Lithuanian SAF-T schema when requested by the VMI.

Businesses operating below the EUR 300,000 threshold are not currently required to generate i.SAF-T files on demand. That said, threshold levels are set by regulatory decision and can be revised downward. Finance teams at companies approaching the threshold should treat system readiness as a near-term priority rather than a future consideration.

i.SAF vs i.SAF-T: Monthly Reporting vs On-Demand Audit Files

i.SAF and i.SAF-T are two separate compliance obligations under Lithuania's i.MAS (intelligent tax administration) system. They differ in what data they cover, when they must be filed, and what triggers the filing. Conflating the two is one of the most common sources of compliance confusion for businesses operating in Lithuania, and the naming convention does not help.

One is a recurring monthly task your team already handles if you are VAT-registered. The other is an on-demand delivery triggered by the State Tax Inspectorate (VMI) that requires a far broader dataset, and it can arrive with little warning.

Dimension	i.SAF	i.SAF-T
What it covers	Purchase and sales invoice data (invoice registers)	Full accounting data: general ledger, journal entries, customer/supplier master data, and tax-relevant transactions
When it is filed	Monthly, by the 20th of the following month	On demand only, when VMI issues a formal request
Who must file	All VAT-registered taxpayers	Taxpayers exceeding the EUR 300,000 annual revenue threshold
What triggers it	Calendar-based recurring obligation	VMI audit activity, tax inspection, or specific data request
File format	XML (i.SAF schema, scoped to invoice data)	XML (i.SAF-T schema, broader structure covering full accounting records)

i.SAF is the obligation most Lithuanian businesses encounter first. It requires the monthly submission of structured invoice-register data to VMI, covering both issued and received invoices. For a deeper walkthrough of that process, see the guide on Lithuania's i.SAF monthly invoice-register reporting requirements. Because i.SAF applies to all VAT-registered entities regardless of size, it functions as the baseline layer of Lithuania's digital tax reporting infrastructure.

i.SAF-T is fundamentally different in scope and trigger. Rather than a recurring calendar obligation, it is activated when VMI requests your accounting data, typically during a tax audit or targeted data check. The data set is substantially larger: VMI expects your general ledger, all journal entries, and master data for customers and suppliers, not just invoice summaries. The XML schema reflects this broader scope, and generating a compliant file requires your ERP or accounting system to export data that many organizations do not routinely package for external delivery.

Both files use XML, but they are not interchangeable. A valid i.SAF submission does not satisfy an i.SAF-T request, and vice versa.

In practice, a business above the EUR 300,000 revenue threshold manages both obligations simultaneously. Your monthly i.SAF submissions continue on their normal schedule regardless of whether an i.SAF-T audit request is active. The two run on independent tracks: one driven by the calendar, the other by VMI enforcement activity. Finance teams that treat them as a single workflow risk gaps in either obligation.

When VMI Requests SAF-T Data: Triggers and Notice Periods

Unlike the monthly i.SAF submissions that follow a predictable calendar, an i.SAF-T request arrives on VMI's terms. Understanding what prompts these requests and how much runway you actually get is essential for any finance team operating in Lithuania.

VMI issues i.SAF-T data requests under several circumstances. The most common triggers include:

Scheduled tax audits, where VMI initiates a comprehensive review of a taxpayer's records for one or more financial periods
Targeted compliance checks, often prompted by anomalies detected in previously submitted i.SAF data or VAT returns
Cross-referencing exercises, where VMI compares transaction data across multiple taxpayers to identify discrepancies in reported purchases and sales

Each request is formal. VMI specifies exactly which financial periods it needs covered and sets a concrete deadline for data delivery. This is not an informal inquiry; it carries legal weight and requires a structured response in the prescribed XML format.

The standard minimum notice period is 10 days. From the date you receive the audit notice, you must deliver the requested i.SAF-T files within at least 10 days. This is a floor, not a ceiling. VMI may grant additional time depending on the scope of the request or the volume of data involved.

That 10-day minimum is negotiable in one direction only: it can be shortened, but only with the taxpayer's explicit agreement. A business with mature data extraction processes might consent to a faster turnaround to expedite the audit. However, if your systems are not ready, you should not feel obligated to accept a compressed timeline. The 10-day baseline exists precisely to protect taxpayers from unreasonable delivery demands.

Some practitioners reference a 30-day period in certain audit contexts. The applicable timeframe depends on the specific type of audit request and its legal basis under Lithuanian tax administration rules. For standard i.SAF-T data delivery requests, the 10-day minimum remains the commonly referenced baseline. When longer periods appear, they typically relate to broader audit proceedings rather than the data submission deadline itself.

VMI can request data reaching back to the start of your obligation. If your business crossed the EUR 300,000 revenue threshold by the time the requirement took effect, you must be able to produce i.SAF-T files for any financial year beginning on or after 1 January 2019. A request in 2026 could therefore cover up to seven years of transactional data. The further back VMI reaches, the more critical it becomes that your archival data remains accessible and exportable in the correct format.

The practical reality of a 10-day window is stark. That is not enough time to reverse-engineer data mappings, reconcile ledger discrepancies, or build an XML export from scratch. Preparation for a VMI request must happen before the notice arrives, not after. Finance teams that treat i.SAF-T readiness as a future project rather than a current capability are betting that VMI will not come calling before they are ready.

How SAF-T Submission Works: Testing, Upload, and Formal Delivery

When VMI requests your i.SAF-T audit file, knowing the format requirements is only half the challenge. The other half is navigating the actual submission workflow: file generation, validation testing, portal upload, and formal acceptance.

The file format is XML, built to Lithuania's adapted SAF-T schema. Your i.SAF-T audit file must be delivered as a structured XML document conforming to the specific schema defined by Lithuanian tax authorities. This schema dictates how your accounting data is organized: general ledger entries, journal transactions, customer and supplier master records, and all tax-relevant details must map to defined XML elements and attributes. A file that deviates from the schema structure, even if the underlying data is accurate, will fail validation.

The VMI Testing Environment

Before you ever face a formal audit request, VMI provides a testing environment where you can upload and validate your prepared SAF-T files. This is one of the most practical tools available to Lithuanian taxpayers, yet it remains largely undiscussed in English-language guidance.

The testing environment lets you check whether your generated XML conforms to the required schema, flag data inconsistencies, and identify formatting issues, all without the pressure of an active audit deadline. You can run validation cycles repeatedly, fix problems in your export process, and confirm that your ERP output meets VMI's expectations. Access the testing environment through your i.MAS portal account. Businesses that use this facility proactively eliminate the single largest risk in SAF-T compliance: discovering your system cannot produce a valid file only after VMI has already made a formal request.

The Five-Stage Lithuania SAF-T Submission Workflow

The end-to-end process for delivering your i.SAF-T audit file follows a defined sequence:

1. Preparation. Generate the SAF-T XML file from your ERP or accounting system covering the specific financial period(s) VMI has requested. This step depends entirely on your system's native SAF-T export capabilities. Some ERP platforms produce compliant XML directly; others require additional modules, custom export configurations, or third-party tools to map your data into the correct format.

2. Validation and Testing. Upload the generated file to the VMI testing environment. The system checks your XML against the schema and reports errors, whether structural issues, missing required fields, or data inconsistencies. Correct any flagged problems in your source system or export process, regenerate the file, and re-test until it passes cleanly.

3. Upload. Submit the validated file through the i.MAS portal, VMI's electronic reporting system. This is the formal submission channel for your Lithuania i.SAF-T audit file.

4. Processing. VMI processes the uploaded file on its side, running additional validation checks beyond what the testing environment covers. This stage is not instantaneous. Depending on file size and system load, processing can take meaningful time.

5. Formal Acceptance or Rejection. Once processing completes, VMI either accepts the submission and records it as formally delivered, or flags errors that require correction. If your file is rejected, you must fix the identified issues, regenerate, and re-submit through the same upload process.

Why Early Submission Matters

The processing stage introduces a variable you cannot fully control. Because VMI's system needs time to process and validate your upload, and because rejection means starting the correction cycle again, submitting early within your notice period is essential. Waiting until the final days of your deadline leaves no margin for processing delays or unexpected rejections. Treat the deadline as your last acceptable date for a successful submission, not your target upload date.

Your submission experience also depends heavily on your finance system's native SAF-T export capabilities. Not all ERP platforms produce compliant Lithuanian i.SAF-T XML out of the box, and discovering that gap during a live audit request leaves no room to recover.

Penalties for SAF-T Non-Compliance

Most guides on Lithuania's i.SAF-T obligations stop short of addressing what happens when a taxpayer fails to deliver. That gap matters, because the consequences extend well beyond a single fine.

When VMI requests SAF-T data and a taxpayer fails to provide it within the required timeframe, enforcement follows under Lithuania's Law on Tax Administration. VMI holds broad powers to compel compliance with data submission obligations, and it uses them.

Administrative fines are the most immediate consequence. Lithuanian tax administration law authorizes penalties for:

Failure to provide requested data within the stipulated deadline
Submission of incomplete or inaccurate files that do not meet the i.SAF-T technical specification
Repeated non-compliance, which can trigger escalating penalty amounts

But direct fines are only the starting point.

Audit escalation is the more consequential risk. If your organization cannot produce a compliant SAF-T file on request, VMI interprets this as a signal that your underlying records may have broader integrity issues. The practical result is predictable: the scope of the audit expands. What might have been a targeted review of specific transactions can become a comprehensive examination of your accounting records, VAT filings, and supporting documentation. This consumes significant internal resources and management attention.

Assessment based on VMI's own calculations represents the worst-case scenario. When a taxpayer's data is unavailable or unreliable, VMI retains the authority to determine tax liabilities using its own methods and available information. You lose the ability to substantiate your positions with your own records, and the resulting assessments rarely favor the taxpayer.

Ongoing scrutiny follows non-compliance as well. Organizations that fail to meet SAF-T requests are flagged for closer monitoring in subsequent periods. This creates a compounding problem: each future filing and reporting obligation receives heightened attention from VMI, increasing the operational burden on your finance and tax teams.

These enforcement dynamics are not unique to Lithuania. Tax authorities across Europe and the OECD are investing heavily in their capacity to detect non-compliance through digital reporting data. According to EY's 2025 Tax Risk and Controversy Survey, 29 of 38 OECD member nations are using some form of AI as part of their tax administration as of 2024, with 79% deploying it specifically to detect tax evasion and fraud. VMI operates within this broader trend, meaning its ability to cross-reference submitted data, identify anomalies, and flag inconsistencies will only grow more sophisticated.

The practical takeaway for financial controllers and tax managers is straightforward: the cost of non-compliance is not limited to the fine itself. Inability to produce a compliant SAF-T file on demand calls into question the reliability of your entire record-keeping framework, and the resulting scrutiny compounds over time.

Preparing Your Finance Systems for a SAF-T Audit Request

The 10-day minimum notice period VMI provides before you must deliver i.SAF-T data is not a preparation window. It is a delivery deadline. If your finance systems are not already configured to produce compliant XML audit files, 10 days will not be enough to map your chart of accounts, resolve data gaps, and troubleshoot schema validation errors. Lithuania tax audit file preparation is an operational project that must be completed well before any request arrives.

The following readiness checklist covers the core areas your finance and ERP teams should address now.

Confirm ERP/Accounting System Export Capability

Verify whether your accounting system can natively generate XML files that conform to Lithuania's i.SAF-T schema. Not all ERP platforms include this functionality out of the box. If yours does not, determine what is needed: a vendor-supplied add-on module, a custom report build, or a third-party extraction tool. Do not assume your system is compliant because it supports SAF-T exports for another country. Lithuania's schema has jurisdiction-specific field requirements, and a generic SAF-T export will fail validation.

Audit Data Quality and Completeness

Incomplete or inconsistent source data is the single most common reason SAF-T files fail VMI validation. Review these records systematically:

General ledger entries — Confirm all transactions are posted, not sitting in draft or suspense accounts.
Customer and supplier master records — Validate that tax identification numbers, legal names, and address fields are populated and current. Missing counterparty data will produce schema errors.
Journal entries — Ensure every journal entry is linked to the correct account codes and periods, with no orphaned or unbalanced entries.

Businesses managing invoice data across multiple sources or formats often find that inconsistencies creep in at the point of data capture. In these cases, tools that automate invoice data extraction into structured formats can help ensure source data is clean and consistently structured before it feeds into SAF-T generation.

Map Your Chart of Accounts to the SAF-T Schema

This is frequently the most time-consuming step. Lithuania's i.SAF-T schema requires transactions to be categorized according to a defined structure that may not align with your internal chart of accounts. You need to create and maintain a mapping table that translates every active account code in your system to its corresponding SAF-T category. Review this mapping whenever you add new accounts or restructure your chart of accounts.

Generate and Validate a Test File

Use the VMI testing environment to submit a sample i.SAF-T file before you face a real audit request. This test run will expose formatting issues, missing mandatory fields, and mapping errors that are invisible until you attempt an actual export. Run test files for multiple reporting periods, not just the current one, to confirm that historical data exports correctly as well.

Verify Historical Data Availability

VMI can request i.SAF-T data covering periods from 2019 onward for most businesses. Confirm that your accounting system retains transaction-level data for this entire range and that it is exportable in the required format. If older data has been archived, migrated, or stored in a legacy system, establish a tested retrieval and conversion process now. Discovering that 2020 data is locked in a decommissioned platform during a live audit request is not a recoverable situation.

Document the Export Process

Your SAF-T export process should not depend on a single team member's institutional knowledge. Create written documentation that covers:

Step-by-step export instructions for your specific ERP system
The chart of accounts mapping table and its update procedure
VMI portal login credentials and submission steps
Known issues and troubleshooting steps from test file generation
Contact information for your ERP vendor's SAF-T support team

Any qualified member of your finance or systems team should be able to execute the full export and submission process using this documentation alone.

Maintain Compliant Data Retention

Lithuanian tax law requires you to retain accounting records for the legally mandated period. Your data retention policies must ensure that all underlying transaction data needed to regenerate a SAF-T file remains accessible for any period VMI may request. This applies not only to your primary accounting system but also to any subsidiary ledgers, document management systems, or archived datasets that feed into the SAF-T export. Periodically verify that retention schedules are being followed and that archived data remains retrievable and exportable.

Audit readiness is not a one-time project. Chart of accounts changes, system upgrades, staff turnover, and evolving VMI schema versions all require you to revisit and revalidate your preparation. Schedule a quarterly review of your SAF-T readiness checklist to ensure that when a request does arrive, your only task is pressing the export button.