From b4b4f1a64db2c5982b0a32e24e1508b27eaa0d3e Mon Sep 17 00:00:00 2001 From: Priec Date: Sun, 19 Jul 2026 20:01:01 +0200 Subject: [PATCH] efaktura legal --- efaktura_2027_report.md | 122 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 efaktura_2027_report.md diff --git a/efaktura_2027_report.md b/efaktura_2027_report.md new file mode 100644 index 0000000..dec10a9 --- /dev/null +++ b/efaktura_2027_report.md @@ -0,0 +1,122 @@ +# eFaktúra 2027 — Slovakia's mandatory e-invoicing: full compliance report + +*Researched 2026-07-19. Sources listed at the bottom.* + +## TL;DR — the one fact that shapes everything + +**You cannot push XML directly to the tax authority, and you cannot push it directly to your customer either.** Slovakia chose a **decentralized 5-corner Peppol model**. Every invoice must travel: *your system → your accredited service provider ("Digitálny poštár" / Digital Postman) → Peppol network → recipient's provider → recipient's system*, with the Financial Administration sitting at corner 5 receiving reported tax data from the providers. So "pushing the XML directly" means one of two legal paths: + +1. **Integrate the ERP backend with the API of one (or several) accredited Digital Postmen** — you generate the compliant XML, they deliver it and handle the tax-authority reporting. This is what virtually every ERP vendor is doing. +2. **Become an accredited service provider yourself** — a Peppol-certified Access Point plus Slovak Financial Administration accreditation. Real option for an ERP company long-term, but it's a regulatory undertaking, not a coding task (details below). + +There is no direct taxpayer→tax-authority channel like Poland's KSeF or Italy's SdI. That's the deliberate design. + +--- + +## 1. Legal framework + +- **Act No. 385/2025 Z.z.**, approved by the National Council on **9 December 2025**, amends the VAT Act (new **§ 76a** on electronic invoices) and transposes Articles 1 and 5 of **Council Directive (EU) 2025/516 (ViDA)**. In force **1 January 2026**; obligations bite **1 January 2027**. +- The **Financial Administration of the SR (Finančné riaditeľstvo)** is the national **Peppol Authority** — it accredits providers, publishes the certified-provider list, and operates corner 5. +- The legal definition of "invoice" is redefined around **EN 16931 (STN EN 16931)**: a structured electronic file enabling automatic processing. **PDF, scans, and EDIFACT legally cease to be invoices** for in-scope transactions. +- A **draft amendment (LP/2026/282, May 2026)** proposes a **penalty-free grace period 1 Jan–31 Mar 2027** and **deferring buyer-side reporting to 1 July 2030**. As of mid-2026 it is *under consultation, not enacted* — build for the strict version, treat the grace period as a bonus. + +## 2. Timeline + +| Date | What happens | +|---|---| +| 1 Jan 2026 | Law in force; voluntary phase begins; provider accreditation starts (rules published 14 Jan 2026) | +| Spring–Q3 2026 | Voluntary testing; corner-5 digital reporting system projected live ~Q3 2026 | +| **1 Jan 2027** | **Mandatory**: structured e-invoicing + near-real-time reporting for all domestic B2B (and B2G) transactions between Slovak VAT payers | +| 1 Jul 2030 | Extends to **cross-border intra-EU** transactions and to **foreign VAT-registered non-established** businesses (ViDA DRR); **súhrnný výkaz (ESL) and kontrolný výkaz (VAT control statement) are abolished** — invoice data reporting replaces them | +| 1 Jan 2035 | ViDA deadline for all national regimes to be harmonized with the EU standard | + +## 3. Who is obligated, and for what + +**Must issue e-invoices (from 1 Jan 2027):** +- Slovak-established **VAT payers**, for **domestic B2B and B2G** supplies with place of supply in Slovakia. +- Foreign businesses VAT-registered in Slovakia **without establishment** are out of scope until **30 June 2030**, then pulled in. + +**Must be able to receive e-invoices:** +- **Every legal entity and entrepreneur — including non-VAT payers.** This is the widest net: even a small non-VAT company must be reachable (registered with a provider, identified by its **DIČ** in the Peppol directory). **Recipient consent is not required** — a compliant e-invoice sent to your Peppol address is legally delivered. + +**Out of scope:** B2C invoices; supplies involving classified information (SIS, Military Intelligence); simplified invoices/cash-register receipts stay under the eKasa regime. + +**Deadlines written into the regime:** +- Issue the e-invoice within **15 days** of the tax event (tightened from the general rule, per ViDA alignment). +- Buyer side: report data from **received** invoices within **5 days** (this is the piece proposed for deferral to 2030). + +**Self-billing** remains permitted with written agreement. **Corrective invoices** (credit/debit notes) follow the same structured-format and reporting rules. + +## 4. Format — what the XML must be + +- **EN 16931** semantic model, in **UBL 2.1** or **UN/CEFACT CII** syntax. In practice Slovakia runs on **Peppol BIS Billing 3.0** (UBL), which is the EN 16931-compliant Peppol profile. +- Slovakia has stated it uses EN 16931 **without a national CIUS/extension** so far — but a Slovak Peppol ruleset is materializing through the Peppol Authority: **Peppol Code Lists v9.5** already define scheme **0245 (SG:DIC)** — the 10-digit Slovak tax ID — as the participant identifier for addressing Slovak entities. +- The XML must pass **EN 16931 business rules (BR-*) validation** plus Peppol BIS validation artifacts, and carry correct Slovak VAT content (DIČ/IČ DPH of both parties, VAT breakdown per rate, correct tax category codes, etc.). + +## 5. Reporting (the "e-reporting" half) + +- For every invoice, the **accredited provider** extracts a **Tax Data Document (TDD)** — a subset of the invoice data — and sends it to the Financial Administration in near real time. Reporting **does not block delivery** (no clearance model — the invoice isn't pre-approved by the state, unlike KSeF/SdI). +- Supplier-side reporting happens at issuance via your provider; buyer-side reporting (within 5 days, possibly deferred to 2030) via the buyer's provider. +- From July 2030 this reporting fully replaces the ESL and control statement. + +## 6. Archiving and integrity + +- Retain invoices **10 years** (immovable property: **20 years**), in the structured electronic form, guaranteeing **authenticity of origin, integrity of content, and legibility** for the whole period. Storage abroad is permitted (must be accessible to the tax authority). + +## 7. Penalties + +- Up to **€10,000** per violation (not issuing/receiving properly, wrong or late reporting); up to **€100,000** for repeated violations. +- Statutory defenses: promptly corrected honest errors; and provider technical outages if data is reported without delay after resolution — one reason the provider contract and failover matter legally. + +## 8. Other countries this affects + +Two distinct senses of "affects": + +**Directly, via the same ViDA directive** — from **1 July 2030** *every* EU member state must run digital reporting for intra-EU B2B transactions, and structured e-invoicing becomes the default EU-wide; Slovakia's mandate is simply an early national implementation. If ERP customers trade intra-EU, the 2030 wave hits all of them regardless of country. + +**Practically, for an ERP serving the region** — neighboring/EU mandates customers may fall under: + +| Country | Mandate | Model | +|---|---|---| +| **Belgium** | 1 Jan 2026, all VAT businesses | Peppol 4-corner (BIS 3.0) — closest to Slovakia | +| **Poland** | KSeF: 1 Feb 2026 (large), 1 Apr 2026 (rest), 2027 (micro) | **Centralized clearance** via state platform, FA(3) XML | +| **Croatia** | 1 Jan 2026 (Fiskalizacija 2.0) | Decentralized exchange + fiscalization reporting | +| **France** | Sep 2026 receive + large issue; Sep 2027 SMEs | PDP (certified platform) model | +| **Germany** | Receive since 2025; issue 2027 (>€800k), 2028 all | No network mandate; EN 16931 (XRechnung/ZUGFeRD) | +| **Hungary, Romania, Italy** | Already live | RTIR / RO e-Factura / SdI clearance | +| **Slovenia** | 1 Jan 2028 | e-SLOG/EN 16931, provider-based | +| **Latvia** | B2G reporting 2026; B2B 1 Jan 2028 | Peppol-based | + +The strategic takeaway: Slovakia, Belgium, Latvia, and the ViDA 2030 endgame all converge on **Peppol + EN 16931/UBL**. Building invoice generation around clean EN 16931 UBL semantics is the one investment that pays off in every one of these markets; Poland's KSeF is the notable divergent (its own XML schema and central API). + +## 9. Compliance checklist — what must exist for Slovak users to be 100% compliant on 1 Jan 2027 + +1. **Outbound**: generate **EN 16931-valid UBL 2.1 (Peppol BIS 3.0)** XML for every domestic B2B/B2G invoice, credit note, and corrective invoice, within **15 days** of supply. +2. **Transmission**: deliver it through an **accredited Digital Postman** — via their API from the backend. The Financial Administration publishes and updates the **list of accredited providers** (first entries expected during 2026); ideally support more than one, since customers may have provider preferences and the outage-defense rules make failover valuable. +3. **Inbound**: every customer entity (VAT payer or not) must be **registered/addressable by DIČ (scheme 0245)** and able to **receive** e-invoices — the system needs to ingest incoming UBL from the provider, not just send. +4. **Buyer-side reporting**: confirmation/reporting of received-invoice data within **5 days** (watch LP/2026/282 — may move to 2030). +5. **Validation**: enforce EN 16931 + Peppol business rules *before* handing off, because a rejected invoice past day 15 is the user's fine. +6. **Archiving**: 10/20-year retention of the structured XML with integrity guarantees. +7. **Transition**: use **2026 as the testing year** — the voluntary phase and Peppol Testbed exist precisely so ERPs can certify their flows before the deadline. +8. **To *be* the pipe**: apply for **Slovak accreditation as a service provider** — EU registered office, clean criminal record for the company and representatives, passed **Peppol Testbed** conformance, reliable sender/recipient identification, and capability to generate and submit **TDDs to corner 5**. That makes you a Peppol Access Point + Slovak Digital Postman, and then the backend genuinely pushes XML "directly" into the network. It's the only legal route to eliminating the third-party middleman. + +**Watch items between now and 2027:** enactment status of **LP/2026/282** (grace period + buyer-reporting deferral), the final **corner-5/TDD technical specification** (system projected live Q3 2026), and the growing **accredited provider list** — all published by the Financial Administration (financnasprava.sk, eFaktúra section). + +--- + +## Sources + +- [European Commission — eInvoicing in Slovakia](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108899/eInvoicing+in+Slovakia) +- [e-Invoice.app — Slovakia Guide (Law 385/2025)](https://www.e-invoice.app/guides/slovakia-e-invoicing) +- [Banqup — Slovakia's 5-corner model](https://www.banqup.com/resources/blog/slovakia-s-next-step-a-5-corner-model-for-e-invoicing-in-2027) +- [VATupdate — eFaktúra FAQ](https://www.vatupdate.com/2026/03/20/slovakias-efaktura-system-faq-on-mandatory-b2b-b2g-e-invoicing-peppol-and-compliance-deadlines/) +- [VATupdate — Digital Postman model](https://www.vatupdate.com/2026/07/09/mandatory-b2b-e-invoicing-from-1-january-2027-digital-postman-model/) +- [Fiscal Solutions — SP accreditation rules](https://www.fiscal-requirements.com/news/5023) +- [KPMG — Slovakia VAT e-invoicing 2027](https://kpmg.com/us/en/taxnewsflash/news/2026/05/slovakia-vat-e-invoicing-implementation-2027.html) +- [Accace — E-invoicing in Slovakia from 2027](https://www.accace.com/e-invoicing-in-slovakia/) +- [Podnikajte.sk — eFaktúra od 2027](https://www.podnikajte.sk/dan-z-pridanej-hodnoty/efaktura-povinna-elektronicka-fakturacia-od-2027) +- [EY SK — Povinná elektronická fakturácia](https://www.ey.com/sk_sk/services/tax/ey-global-tax-e-invoicing-solution-sk/povinna-elektronicka-fakturacia-od-roku-2027) +- [Marosa — E-invoicing in Europe overview](https://marosavat.com/resources/e-invoicing-in-europe-overview-and-dates) +- [Fiskaly — EU e-invoicing roadmap 2026](https://www.fiskaly.com/blog/e-invoicing-mandates-in-europe-2026) +- [EDICOM — Slovakia e-invoicing project](https://edicomgroup.com/blog/slovakia-continues-to-advance-its-einvoicing-project) +- [Comarch — Slovakia 2027 clarifications](https://www.comarch.com/trade-and-services/data-management/legal-regulation-changes/slovakia-publishes-clarifications-on-2027-e-invoicing-and-e-reporting-mandate/)