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.

That is why a current Ukraine standard audit file for tax guide has to focus on operational readiness rather than rollout theory. 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. For finance leaders, the takeaway is clear: once a request arrives in the audit context, the discussion shifts quickly from policy interpretation to evidence production.

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?"

The 2025 to 2026 Milestones That Changed the SAF-T UA Picture

Older English-language commentary often frames SAF-T UA as a draft-era or future-filing topic. The 2025 to 2026 record shows something more concrete: FAQ clarification, live testing volumes, first real audit use, and continued refinement inside Ukraine E-audit.

• March 4, 2025: The STS published an FAQ notice that clarified practical questions for large taxpayers and helped shift the discussion away from vague rollout language toward operational expectations.
• June 6, 2025: The STS reported 34 taxpayers participating in test mode and 261 files submitted, showing that SAF-T UA testing was active rather than theoretical.
• July 23, 2025: The STS updated those figures to 41 taxpayers and 415 files, which mattered because it showed broader participation and a growing body of tested submissions.
• September 4, 2025: The first clear practical documentary-audit use was reported in connection with a VAT refund audit, confirming that SAF-T UA had crossed from sandbox-style preparation into actual audit procedure.
• October 24, 2025: The STS announced the first test-mode submission completed without FE or RE errors, a strong signal that both taxpayers and the authority were refining file quality and validation expectations.
• January 1, 2026: The official E-audit launch notice marked the start of a new phase, making it harder to treat SAF-T UA as a distant future obligation.
• January 2, 2026: A TOP-10 FAQ followed immediately, reinforcing that the authorities expected recurring practical questions from large taxpayers and their advisers.
• March 3, 2026: Another Electronic Cabinet testing update confirmed that the pre-request testing path remained an active part of the process, not a one-off pilot.

The September 4, 2025 VAT refund audit example is the key turning point. Once the STS described SAF-T UA being used in a real documentary audit, the topic stopped being only about pilot testing and started looking like live audit evidence production.

Viewed together, these milestones show a request-driven readiness program rather than a settled recurring SAF-T calendar. That is why Ukraine is easier to understand alongside Bulgaria's phased SAF-T rollout and data-readiness timeline and Romania's D406 reporting and audit-file preparation model, while still remaining distinct in its current emphasis on on-request submission and pre-request testing.

---

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.

For that reason, SAF-T UA preparation should not sit with one person waiting for an audit notice. Finance usually owns the business meaning of the data, tax interprets what the STS is likely to expect in an E-audit context, and ERP or accounting admins control the source mappings and extract logic. If those groups do not test together, you may get a file that is technically valid but substantively weak, or a file that reflects the right accounting logic but fails at submission. Shared ownership is what turns testing from a last-minute export into a repeatable readiness process.

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.

Most of these failures come from the same root causes: incomplete master data, unstable chart-of-accounts mapping, weak document references, and registers that do not reconcile cleanly with each other. A file can be structurally complete and still not be dependable for documentary audit if period coverage is incomplete, identifiers are inconsistent, or source records cannot be traced cleanly back to supporting documents.

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.