Slovakia’s e-invoicing and e-reporting regime, introduced under Law No. 385/2025 Z.z., uses a decentralised 5-corner Peppol model. Alongside every structured invoice exchanged between a supplier (Corner 1) and a buyer (Corner 4) through their respective Digital Postmen (Corners 2 and 3), the sender’s Digital Postman must also transmit a Slovak Tax Data Document (SK TDD) to the Financial Administration, which operates as Corner 5 (C5). This near-real-time reporting channel gives the tax authority visibility into every domestic B2B and B2G transaction without blocking or pre-clearing the invoice itself.
This article summarises how a TDD is sent to C5, what must be true for it to be accepted, and what happens when it isn’t.
1. Where to Send
Recipient: The Financial Administration’s C5 endpoint is addressed on the Peppol network using its published participant identifier. Businesses themselves are identified on the network by scheme 0245:XXXXXXXXXX, where the ten-digit value is the Slovak Tax Identification Number (DIČ) of the economic subject.
Endpoint: As with any Peppol document, the C5 endpoint must be resolved dynamically through the SML/SMP lookup chain — never hard-coded — and delivery happens over the standard Peppol AS4 transport profile.
Payload: A single SK TDD document per invoice, carried in an SBDH envelope over AS4. The TDD itself carries no attachments; it is a structured data extract of the invoice (parties, invoice number and date, supply or payment date, quantities, taxable base, VAT rate and amount, exemption or reverse-charge indicators, and correction references where relevant) rather than the invoice document itself.
2. Transport Prerequisites
All of the following must hold, or the message is refused at the AS4 level:
- The document type is a valid SK TDD. Any other document type submitted to the C5 corner is rejected.
- The sender is registered and known to the Financial Administration’s SMP as an accredited Digital Postman.
- The message is structurally valid per the Peppol AS4 profile.
- It is signed with a valid Peppol certificate issued to a certified provider.
- It is encrypted to the Financial Administration’s certificate.
An AS4 Acknowledgment is returned immediately on receipt; validation and tax-side processing follow asynchronously.
3. The 15-Minute Reporting Window
Unlike a generic Peppol document exchange, the SK TDD carries a hard timing constraint: it must reach the Financial Administration within 15 minutes of the invoice being transmitted to the buyer’s Digital Postman. In the standard supplier-issued flow, the sender’s Digital Postman (C2) transmits the invoice to the buyer’s Digital Postman (C3) and reports the TDD to C5 in parallel — the two are not sequential steps. A separate buyer-side TDD flow (C4 → C3 → C5) applies mainly to self-billing scenarios, not to every invoice a business receives.
4. Document Validation
Every TDD is validated against the EN 16931-aligned Slovak schema and business rules (Schematron), consistent with the UBL 2.1 or CII syntax used for the underlying invoice. A TDD that fails validation is not stored; the Financial Administration returns a negative response describing the errors, and the sending Digital Postman is expected to correct and resubmit within the same reporting window wherever possible.
5. Message Size and Format
The TDD is a lightweight structured extract with no attachments. PDF and EDIFACT representations are not accepted anywhere in this regime — only EN 16931-compliant structured formats are supported.
The Bottom Line
Slovakia’s 5-corner Peppol model makes near-real-time tax reporting a parallel part of every invoice exchange. Digital Postmen must resolve the C5 endpoint dynamically, transmit one valid SK TDD per invoice over AS4, and meet the 15-minute deadline. Correct participant identifiers, valid Peppol certificates, schema compliance, and rapid error handling are essential for successful reporting.
For an SAP-focused technical perspective, read the SAP E-Invoice guide to Slovakia TDD reporting to Peppol Corner 5.