Yevheniia Abrosymova,
Transfer Pricing Partner
Table of Contents
Picture this scenario: late on a Friday afternoon, the chief accountant of a large enterprise receives a request from the tax authority to provide a SAF-T UA file. The deadline to prepare it is two business days. Not two weeks, not a month. Two days to export, review, and submit a structured electronic file containing every single journal entry, source document, and cross-reference for the audit period.
For most companies, this is the exact moment when it becomes clear that “we seem to have a SAF-T module” and “it actually works properly” are two completely different things.
What SAF-T UA Really Is — and Why It’s Not Just “Another Report”
Technically, SAF-T UA is an XML file that must strictly comply with the official XSD schema of the State Tax Service. However, reducing its essence to a mere “file format” is a classic mistake that comes at a high price later. SAF-T demands not just exporting data, but doing so in a **fully reconciled manner, with complete inter-document linkages and correct classification of every single transaction**. It is effectively an x-ray of your company’s entire accounting logic — and any fracture in that logic becomes visible instantly.
Two Traps Most Companies Fall Into
Trap One: “We have a license for the module — so we are ready”
Trap Two: “We passed XSD validation — the file is correct”
This is where one of the most common illusions of security lies. A SAF-T file undergoes verification on two distinct levels:
- Level One — Structural: verifying whether all mandatory XML elements are present and whether data types are valid. A technical software module handles this automatically, and passing it reveals nothing about the actual quality of the data inside.
- Level Two — Substantive: verifying whether balances reconcile across file sections, general ledger balances, and previously filed tax returns; whether each sales document links to its respective tax invoice; and whether every operation is classified correctly by VAT rate and tax category.
This is where true readiness is tested — and this level is most often left unverified until it is already too late to fix.
What It Actually Means to “Be Ready”
Three levels of internal review before receiving a tax inquiry:
-
Master Data and Registers: Whether counterparty profiles are complete, the chart of accounts is current, and analytical sub-ledgers provide sufficient granularity for accurate mapping to the SAF-T structure.
-
Reconciliation of Balances: Whether transaction totals in a test SAF-T export match the accounting system records and the already submitted tax declarations. A discrepancy of even a few hryvnias is a signal that must be investigated, never ignored.
-
Document Linkage and Transaction Classification: Whether every document in the file contains valid cross-references to corresponding records, and whether tax rates and tax codes are correctly identified for non-standard transactions — exports, commission/intermediary agreements, gratuitous transfers, and related-party operations.
The last point is the most complex, and this is where automated software tools fall short. Only a qualified specialist who understands both company accounting policies and the nuances of tax legislation can accurately categorize atypical transactions. That is the exact boundary where an IT module stops and accounting methodology begins.
The Main Takeaway for Business
Practical Recommendation
The practical recommendation is simple: do not wait for a formal tax inquiry to discover whether your company is ready. Run a readiness diagnostic in advance — while you still have the time to fix what is found, rather than having to justify it to the tax authorities after the fact.
Need a Consultation?
