Slovakia VAT Control Statement: Filing Guide

The Slovakia VAT control statement, or Slovakia kontrolny vykaz, is an electronic XML filing that VAT payers generally submit within 25 days after the end of each tax period.

At a glance:

• The Financial Administration guidance on filing Slovakia's VAT control statement says VAT payers submit it electronically, in XML format, within 25 days after the end of the tax period.
• It routes invoice, simplified-invoice, correction, and eKasa turnover data into sections A.1, A.2, B.1, B.2, B.3.1, B.3.2, C.1, C.2, D.1, and D.2.
• Deductible simplified invoices split between B.3.1 and B.3.2 depending on whether total deducted VAT for the period is below EUR 3,000 or at least EUR 3,000.
• D.1 covers eKasa-recorded turnover, and incomplete or incorrect filings can require a corrective or additional control statement.

In practice, this is part of Slovakia's VAT reporting control framework under VAT Act No. 222/2004 Coll. It is designed to let the tax authority cross-check declared output VAT and claimed input VAT from transactional data, not to serve as a generic attachment to the VAT return.

If you file regular Slovak VAT returns as a VAT payer, assume kontrolny vykaz is part of the same reporting cycle. If you are registered only for narrower cross-border cases, verify the specific period obligation before preparing XML. Submission is electronic through the Financial Administration of the Slovak Republic, typically via eDane or the tax portal, using an XML filing format. Depending on how the taxpayer files, a qualified electronic signature may be required, unless an approved electronic-delivery arrangement applies.

The fastest way to prepare a live Slovakia VAT control statement is to sort source documents into the right reporting buckets before you touch the XML. That matters because one period can include standard invoices, simplified invoices, prepayments, corrective documents, and eKasa receipts at the same time. The rest of this guide follows that document-routing logic, so you can see how each document type lands in A, B, C, or D rather than treating the kontrolny vykaz as an abstract tax form.

How A.1 and A.2 Route Your Sales-Side Invoices

In the Slovakia VAT control statement sections, Part A is the supplier-output side of the filing. Read it as a routing question: what document did you issue, who received it, and who is legally responsible for the Slovak VAT on that supply. That last point is the real divider between A.1 and A.2, and it is where many English-language summaries become too vague.

A.1 is the default home for your issued full invoices when you, as supplier, charge Slovak VAT on the domestic taxable supply. This is where you report each invoice you were required to issue with the standard invoice particulars under Slovak VAT rules, including full invoices tied to taxable supplies and advance-payment invoices where a full invoice is required. If your document is a standard VAT invoice showing the taxable base and the Slovak VAT you are charging, you usually start your review with A.1.

A.2 is narrower. It is for issued invoices covering domestic supplies where the recipient, not the supplier, is the person liable to pay the tax under Slovakia's domestic reverse-charge rules referenced in the official guidance. You still issued the invoice, so it remains on the supplier side of the kontrolny vykaz, but the VAT liability sits with the customer rather than with you. The distinction is not "sales invoices versus other sales invoices," but supplier-charged invoices versus supplier-issued invoices where the customer bears the tax.

A quick operational test helps:

• If you issued a standard taxable invoice and you charge Slovak VAT, think A.1.
• If you issued a domestic reverse-charge invoice and the customer accounts for the tax, think A.2.

Whichever route you choose, the filing only works if the source documents and the XML tell the same story. Keep invoice numbering, customer identification, issue date, tax point logic, tax base, and VAT treatment consistent from the original document through to the control statement. The same discipline matters for prepayments and staged supplies: if your process creates an advance invoice, a settlement invoice, or multiple invoices for one commercial arrangement, your dates, references, and amounts need to line up so the filing reflects the commercial sequence correctly.

If you work across Central European VAT reporting, the logic is easier to remember when you compare it with Czech kontrolni hlaseni and its invoice-reporting structure: both systems depend less on broad tax theory and more on whether each issued invoice has been classified into the correct reporting bucket before submission.

How B.1, B.2, B.3.1, and B.3.2 Route Purchase-Side Data

The B section is the recipient-input side of the Slovak VAT control statement. Under current Slovak Financial Administration guidance, this is where you report incoming documents based on how Slovak VAT is being handled on the buyer side: either you are the person liable to pay the tax, or the supplier charged VAT and you are claiming an input deduction for that period. For AP and compliance teams, the safest approach is to classify each document before you build the filing.

Section	What belongs there	How to think about it
B.1	Received supplies where the recipient is liable to pay Slovak VAT under the relevant reverse-charge rules	Buyer accounts for the tax
B.2	Ordinary received invoices where the supplier is liable for Slovak VAT and the buyer deducts VAT in that period	Supplier charged VAT in the normal way
B.3.1	Deductible simplified invoices when total deducted VAT from those documents for the period is below EUR 3,000	Period-level aggregate reporting
B.3.2	Deductible simplified invoices when total deducted VAT from those documents for the period is EUR 3,000 or more	Aggregate reporting by supplier VAT ID

B.1 is the reverse-charge bucket on the purchase side. In plain English, it covers received supplies where the recipient is the person liable to pay the tax under the Slovak reverse-charge rules cited in the official guidance. If your business must account for the Slovak VAT itself because the transaction falls into that reverse-charge category, the document belongs in B.1, not in the ordinary purchase-invoice section.

B.2 is the standard input-VAT bucket. It covers ordinary received invoices where the supplier is the person liable for the Slovak VAT and you are claiming an input deduction in that reporting period. If you received a normal full invoice, the supplier charged Slovak VAT, and your team is taking the deduction now, B.2 is usually the right destination.

The hardest part of Slovakia simplified invoice reporting in the kontrolny vykaz is separating full invoices from simplified invoices. The split matters because B.3 is not a lighter version of B.2. It is a separate reporting track for documents that qualify only as simplified invoices. Under the official B.3.1 and B.3.2 guidance, B.3.1 is used when the total deducted VAT from simplified invoices for the period is below EUR 3,000, while B.3.2 is used when the total deducted VAT from simplified invoices for the period is EUR 3,000 or more.

That threshold changes how you report, not just where you report. In B.3.1, you give aggregate totals for the period. In B.3.2, you still report totals from simplified invoices, but you must break them out by supplier VAT ID for the same period. So the operational step is simple: isolate all deductible simplified invoices first, total the deducted VAT for the period, then decide whether you are in B.3.1 or B.3.2.

A receipt or eKasa document used as a simplified invoice for input deduction belongs on the buyer side in B.3.1 or B.3.2 if you are actually deducting VAT from it in that period. If no deduction is claimed, it should not be included there. This is where teams often go wrong: they treat every receipt-style document as automatically reportable, when the real test is whether it is being used as a deductible simplified invoice in that filing period.

The practical distinction between B.2 and B.3 is this:

• If the document contains all the particulars of a full invoice, route it to B.2.
• If the document only qualifies as a simplified invoice, route it to B.3.1 or B.3.2 depending on the EUR 3,000 threshold.
• If the transaction is subject to Slovak reverse charge and the buyer is liable for the tax, route it to B.1.
• If no input deduction is being claimed in that period, do not force the document into B.2 or B.3 just because it exists in your AP records.

For filing prep, that gives you a workable sorting method: first separate reverse-charge inputs, then ordinary supplier-charged invoices, then simplified invoices such as deductible receipt or eKasa documents. Once those three pools are clean, the B section becomes a data-routing exercise instead of a line-by-line judgment call.

Where C.1, C.2, D.1, and D.2 Catch Corrections, eKasa Turnover, and Receipt-Style Documents

This is where many Slovakia VAT control statement errors happen, because corrections and receipt-style documents do not follow the same routing logic as ordinary invoice lines. Keep one rule in mind: C-sections are for corrective invoices, D-sections are for supplier-side aggregates.

C.1 is the supplier-side correction section. Use it for corrective invoices you issue when the original transaction belonged in the ordinary, individually reported invoice logic rather than in the D aggregates. If you issued a normal invoice and later reduced, increased, or otherwise corrected it, that correction usually belongs in C.1. What does not belong in C.1 are corrections that stay inside the D totals, such as corrections tied to eKasa turnover already reported in D.1 or corrections to other simplified-output documents already captured in D.2.

C.2 is the mirror image on the recipient side. Use it for received corrective invoices when your input VAT deduction position changes because a supplier corrected the original document. That includes corrective invoices linked to received simplified invoices that originally flowed through B.3.1 or B.3.2. So if your team claimed deduction from a purchase-side simplified document and later receives a correction, the correction does not go back into B.3.1 or B.3.2. It is routed into C.2 for the period in which that corrective invoice is received.

D.1 is different because it is not an invoice-by-invoice list. It is the total turnover recorded through all of your eKasa cash registers for the period, including adjustments that affect that turnover total, such as returns, discounts, and other negative turnover items. For a Slovakia eKasa D.1 control statement, think in terms of the register's aggregate turnover, not one receipt per row. If you need background on receipt mechanics, Slovakia's eKasa receipt and QR-code rules help explain why these documents often sit in a separate operational stream from full invoices.

The overlap rule matters. An eKasa document can contain all the particulars of a full invoice and therefore be reportable in A.1. But if that same document is part of the overall turnover captured by eKasa and you cannot practically strip it out of the register total, it can still remain inside the D.1 aggregate. That is why D.1 is best understood as a turnover capture section, not just a bucket for "simple receipts."

D.2 covers the supplier-side simplified-output cases that are not D.1. Use it for taxable supplies shown on simplified invoices other than eKasa receipts, plus taxable supplies for which you were not required to issue an invoice. The dividing line is operational: D.1 is about turnover captured through eKasa, while D.2 is about other simplified-output cases that do not belong in that eKasa turnover total.

A practical routing summary:

Document type	Report in	Why
Correction invoice on an ordinary issued invoice	C.1	It corrects an individually reported supplier-side invoice
Received correction invoice affecting an input deduction	C.2	It changes the buyer-side deduction position, including corrections to purchase-side simplified invoices
Register-driven turnover from eKasa	D.1	The statement expects aggregate eKasa turnover totals
Other simplified-output cases outside eKasa turnover	D.2	They are supplier-side simplified documents, but not part of D.1

If your filing team is unsure where a document belongs, the fastest test is to ask what system generated the original record and whether the statement expects an individual correction line or an aggregate turnover total. That one check usually separates C.1/C.2 cases from D.1/D.2 cases before XML preparation starts.

When to File an Opravny or Dodatočný Kontrolny Vykaz

First, separate two corrections that teams often blur together. Correcting the commercial document means issuing or receiving a corrected invoice, credit note, or other adjusting document. Correcting the filed kontrolny vykaz means fixing data that was already submitted in the Slovakia VAT control report. Those are different actions. A corrected invoice may belong in the proper correction section for the period, but you only amend the control statement if the filed rows, references, or cumulative totals were incomplete or wrong.

Use an opravny kontrolny vykaz, a corrective control statement, when you find the error before the filing deadline expires. In plain English, this is a full replacement filing. It does not report only the difference. You restate the entire control statement with all correct data, including lines that did not change, and the original filing is disregarded.

Use a dodatočný kontrolny vykaz, an additional control statement, when you find the error after the filing deadline. This works differently. You do not rebuild the whole return. Instead, you report only the rows that need to be corrected, added, or reversed compared with the last valid filing. That matters when you discover a wrong invoice number in A.2, a missing purchase invoice in B.2, or a bad cumulative amount in a D section after submission.

Operationally, the code-1/code-2 logic is a cancel-and-restate method. Code 1 cancels the wrong row that was previously filed. Code 2 adds back the same transaction with the correct values in every relevant column. If the problem sits in a cumulative section such as D.1 or D.2, do not try to adjust only part of the amount. You correct the entire affected line for that VAT rate: one line to reverse the old total, one line to restate the correct total.

A control-statement correction does not automatically mean you also need an amended VAT return. If the VAT return values themselves did not change, but the invoice-level detail in the control statement was incomplete, misclassified, or inaccurate, you may need only the control-statement correction. That distinction is useful because many filing errors are detail errors, not return-total errors.

The urgency is real. Under the 2023 methodological guidance, late filing, non-filing, incomplete data, incorrect data, or failure to fix defects after a tax-office request can lead to Slovakia VAT control statement penalties of up to EUR 10,000, with repeated breaches rising to EUR 100,000. For any team preparing a live Slovakia VAT control report, that makes remediation a workflow issue, not just a technical tax point.

Before you file, reconcile invoice counts, correction documents, simplified-invoice totals, and eKasa totals against the rows you expect in each section. That control step is the fastest way to reduce repeat errors and avoid another additional control statement.

How to Prepare Source Data Before You Build the XML Filing

Before you generate XML for a Slovakia VAT control statement, build a reviewable source dataset first. Once you know which section each document belongs in, the job becomes much easier if you prepare one working file that shows the source document, its destination section, and the core fields you will need for the XML.

Here is a compact example of how one filing period can map:

Source document	Report in	Why
Issued domestic VAT invoice to a Slovak customer	A.1	Supplier charges Slovak VAT on a full invoice
Issued domestic reverse-charge invoice	A.2	Customer, not supplier, accounts for the tax
Received full supplier invoice with deductible Slovak VAT	B.2	Supplier charged VAT and the buyer is deducting it
Deductible simplified receipt for the period	B.3.1 or B.3.2	The destination depends on whether total deducted VAT from simplified invoices stays below or reaches EUR 3,000
Received credit note correcting an earlier deductible purchase invoice	C.2	The correction changes the buyer-side deduction position
eKasa-recorded retail turnover	D.1	The filing expects aggregate turnover from the cash-register system

For each document, capture the same core fields every time: supplier and customer VAT identifiers where relevant, invoice number, issue date, supply date or advance-payment date, taxable base, tax amount, total, any correction reference, and a flag showing whether the document belongs in a full-invoice or simplified-invoice workflow. If your period includes credit notes or other amendments, keep the link back to the original invoice visible in the working file instead of trying to reconstruct it during final review.

Treat traceability as part of the dataset, not as a final check. Each line you expect to report should be traceable back to the underlying invoice, receipt, corrective document, or source file, because the whole point of kontrolny vykaz is cross-checkability between counterparties and between the filing and your bookkeeping record. This preparation step matters most when the period mixes ordinary invoices, simplified receipts, eKasa turnover, and credit notes, because classification mistakes made upstream usually become control-statement mistakes downstream.

If you are standardizing mixed source files before review, AI invoice extraction for VAT reporting can support the preparation stage. Tools like Invoice Data Extraction can help separate full invoices from simplified receipts, capture invoice numbers and tax amounts consistently, keep credit-note links visible, and preserve source-file and page references for review. The practical value is a cleaner dataset before filing, not outsourcing the tax decision.

Use this review sequence before you generate the XML:

1. Confirm the filing period and remove documents that belong to a different reporting window.
2. Classify every document into issued invoices, received invoices, simplified invoices, eKasa receipts, or correction documents.
3. Reconcile the working dataset against the section totals you expect to report so A, B, C, and D entries tie back to the books.
4. Review all corrections separately, checking that each amendment still points back to the original document and the right period logic.
5. Generate the XML only when the underlying dataset is stable, the section totals reconcile, and every reported line can be traced to a source file.