Ukraine SAF-T UA Guide: Testing, Audits, and Requirements

Ukraine SAF-T UA is Ukraine's standardized XML audit file for tax, used by the State Tax Service of Ukraine during documentary audit rather than as a routine periodic filing. For large taxpayers, the practical point is that the file is usually submitted only when requested, the response window is generally two working days, and pre-request testing is now available through the Electronic Cabinet. According to an official STS update on 415 SAF-T UA test submissions, by July 23, 2025, 41 taxpayers had already created and submitted 415 SAF-T files in testing, showing the format is already operational in practice.

A useful Ukraine SAF-T guide should therefore focus less on rollout theory and more on operational readiness. For finance leaders, tax managers, ERP admins, and advisers, the question in 2026 is not whether SAF-T UA exists. It is whether your team can produce a clean XML audit file on short notice, validate the data behind it, and avoid discovering critical gaps only after a documentary-audit request arrives.

Who Needs to Prepare and When the STS Can Request the File

For practical purposes, Ukraine SAF-T UA requirements matter most to large taxpayers and to the finance, tax, ERP, and advisory teams that support them. If your group falls into the large-taxpayer perimeter in Ukraine, SAF-T UA is not something to leave with IT alone. It sits at the intersection of accounting policy, master data, transaction controls, and audit response.

The key distinction is this: mandatory does not mean routine. SAF-T UA is not currently a standing monthly or quarterly submission cycle in the way some finance teams expect from other digital reporting regimes. Instead, the operational trigger is a documentary audit. When the State Tax Service requests the SAF-T UA file as part of that process, the obligation becomes real and time-bound.

At a high level, the file is designed to give the tax authority a structured view of the records behind your tax position. That means accounting data, accounting registers, tax-relevant transactional information, and the standardized file structure needed for audit review. In practice, that can pull together ledger-level information, document-linked entries, reference data, and the relationships that help reviewers trace how figures move from source transactions into reporting.

The procedural framework matters, but it does not need to become a legal memo for your operating team. The current SAF-T UA documentary audit model is tied to the State Tax Service's approved format and validation approach under Order No. 1393, and to the taxpayer obligation to provide requested documents and information under Article 85.2 of the Tax Code of Ukraine.

That is where the two-working-day response expectation becomes operationally important. If you wait until the audit notice lands to figure out data ownership, mapping gaps, chart-of-accounts inconsistencies, or missing accounting registers, you are already late. The short response window means preparation has to happen before the request, not after it.

This request-based model is also why multinational teams should avoid importing assumptions from other SAF-T jurisdictions. In some countries, the habit is to think in terms of scheduled submissions, thresholds, and recurring delivery workflows, such as Lithuania's i.SAF-T threshold and submission workflow. Ukraine's current model is different. The immediate question is not, "What is our monthly SAF-T filing date?" It is, "If the STS opens a documentary audit and asks for SAF-T UA, can we produce a technically valid, audit-ready file within the required timeframe?"

Why SAF-T UA Matters Now

The important change is not any single date. During 2025 and early 2026, STS communications moved SAF-T UA from draft-era discussion into practical testing and audit use: published FAQ guidance, growing Electronic Cabinet test submissions, reported VAT refund audit use, and continued FE/RE validation feedback.

For finance teams, that is enough to treat SAF-T UA as an audit-readiness obligation rather than a future rollout topic. The comparison with Romania's D406 reporting and audit-file preparation model is useful, but Ukraine remains distinct in its current emphasis on on-request submission and pre-request testing rather than a settled recurring calendar.

How Electronic Cabinet Testing Works Before an Official Request

The SAF-T UA Electronic Cabinet testing route, reaffirmed by the STS in its March 3, 2026 update, is best understood as a readiness exercise for Ukraine E-audit, not as a standing filing obligation. Large taxpayers can use it to generate and submit a SAF-T UA XML file before any official documentary-audit request arrives, then use the feedback to find defects while there is still time to fix them calmly.

At a practical level, the workflow is iterative:

1. Generate the SAF-T UA XML file from your ERP, accounting, tax, and master-data sources.
2. Submit that file through the Electronic Cabinet in test mode.
3. Review the validation feedback and identify whether the issue is structural, mapping-related, or caused by underlying source data.
4. Correct the export logic, field mappings, reference data, or accounting records.
5. Regenerate the file and test again until the submission is materially cleaner.

Many problems do not appear when teams review spreadsheets or internal extracts. They surface only when the file is assembled in the required SAF-T UA structure and checked against the validation logic used in the Electronic Cabinet. Pre-request testing helps you discover those issues early, instead of discovering them after the State Tax Service has already requested the file during a documentary audit.

Testing does not turn SAF-T UA into a routine periodic return. The file remains request-driven. The value of SAF-T UA Electronic Cabinet testing is earlier detection, faster correction cycles, and a better chance that the first real submission is usable.

The January 2, 2026 TOP-10 FAQ also showed why this is not just a file-generation exercise. The STS highlighted practical formation questions around optional elements, subaccounts, customs declarations, local taxes, counterparties without VAT registration, and accounting certificates. Teams are not only testing whether the XML can be produced correctly. They are also testing whether their treatment of awkward real-world cases will hold up when the file is reviewed.

Why FE and RE Errors Happen and What They Usually Reveal

FE and RE validation errors are best read as readiness signals, not just technical glitches. A file can be generated successfully while the structure, mandatory field population, or accounting logic behind it is still too weak for reliable SAF-T UA submission.

FE issues usually point to file formation, identifiers, coding, or required-field population. RE issues more often expose inconsistencies between the file and the accounting reality it is supposed to represent. If the same Ukraine SAF-T file errors keep returning, they usually trace back to unresolved master-data, mapping, or reconciliation defects upstream.

Several error areas deserve special attention because they tend to recur in Ukraine SAF-T UA requirements and STS test feedback:

• Inventory balances: These errors often mean item masters are incomplete, movement records do not reconcile to closing balances, units of measure are inconsistent, or stock transactions are posted in one register but not reflected cleanly in another.
• Non-current assets: Failures here usually reveal missing asset-card details, inconsistent depreciation records, gaps between the fixed asset register and the general ledger, or asset events that were documented operationally but not mapped correctly in the export.
• VAT payer tax numbers: A rejected identifier often points to basic reference-data problems, such as outdated taxpayer details, formatting inconsistencies, missing country or registration elements, or supplier and customer records that were never standardized across systems.
• Account or sub-account coding: These errors commonly show that your chart-of-accounts mapping is not stable enough for SAF-T UA. Local accounts, sub-accounts, dimensions, or posting classes may exist in the ERP, but the export logic may be assigning them inconsistently or leaving gaps in required classification fields.

Before generating another test file, focus your review on four practical checks:

• Identifiers: Confirm VAT numbers, taxpayer IDs, asset IDs, inventory item codes, and counterparty records are populated consistently and in the expected format.
• Period coverage: Make sure the requested period is complete, with no missing opening balances, partial transaction loads, or cut-off mismatches between modules.
• Ledger mappings: Check whether each relevant account and sub-account maps consistently from source system to SAF-T UA output, especially where local ERP logic uses custom dimensions or posting rules.
• Source-document support: Verify that ledger entries can be traced to invoices, adjustments, goods movements, asset records, and other supporting documents without broken references.

Most Ukraine SAF-T file errors are not random. They usually reveal where your accounting registers, master data, and supporting records still need repair before the file is submission-ready.

A Practical SAF-T UA Readiness Checklist for Finance, Tax, and ERP Teams

Treat readiness as a cross-functional operating task, not a tax-only project. Use this checklist for the next quarter:

• Assign clear ownership. Name one business owner in tax or finance, one ERP or data owner, and one backup reviewer who can coordinate the response if the STS request arrives during leave periods or month-end pressure.
• Confirm taxpayer scope. Recheck whether the Ukrainian entity falls within the large taxpayers population and whether any recent organizational changes affect who must prepare for SAF-T UA requirements.
• Map ERP fields to SAF-T UA structures. Document where each required field comes from, including master data, general ledger, subledgers, tax attributes, and reference tables, so the team is not reverse-engineering mappings after a request.
• Validate accounting-register completeness. Test whether your accounting registers are complete, internally consistent, and exportable in the form needed for SAF-T UA, especially where local books depend on multiple systems or manual adjustments.
• Check supporting-document retention. Make sure invoices, contracts, adjustments, and other audit support can be retrieved quickly and linked back to the transactional records in the file.
• Clean tax identifiers and master data. Review TINs, counterparty identifiers, chart-of-accounts codes, VAT-related fields, dates, currency logic, and document numbering for gaps or formatting problems that tend to trigger validation issues.
• Set a repeatable testing cadence. Do not rely on a one-off exercise. Schedule periodic test generation and validation so issues are surfaced while there is still time to fix source data and process gaps.
• Rehearse the two-working-day response process. Run a tabletop drill that starts with a mock STS request and ends with a packaged file, internal review, and sign-off. That is the fastest way to expose missing data sources, unclear approvals, and weak handoffs.
• Avoid copy-pasting assumptions from other countries. If your group already handles SAF-T elsewhere, remember that Ukraine SAF-T UA requirements, testing flow, and audit use should be treated as jurisdiction-specific, not interchangeable with other standard audit file programs.
• Strengthen upstream discipline. Better source records make SAF-T preparation less reactive, which is one reason many teams review their invoice and financial document automation workflows alongside tax and ERP controls.

A team is better prepared when it can generate a test file on demand, explain the data lineage behind each major section, and correct FE or RE validation issues without a last-minute scramble. That is the operational standard worth aiming for before the next audit request arrives.