Guide: Specific use for Slovakia

Slovakia uses the prefix 0245 for the tax identifier (DIČ). A company needs this identifier to be on the network and to meet its obligation to send and receive electronic invoices.

Slovakia has two identifiers that are easy to mix up:

• DIČ (daňové identifikačné číslo) is the 10-digit tax identifier that every taxable person has. It is the participant ID on the network, for example 0245:1234567890.
• IČ DPH (identifikačné číslo pre DPH) is the VAT identifier, which only VAT payers have. It is SK followed by the same 10 digits, for example SK1234567890. On the invoice it is the seller's VAT identifier (BT-31). Whether it is there decides if the invoice is reported to the tax authority.

Workflow

Slovakia uses the Peppol BIS3 invoice and credit note formats. Self-billing invoices and credit notes are also supported for both Messaging Services and Transaction Services.

Unimaze creates the tax report and submits it to the Slovak tax authority for the seller: for invoices and credit notes you send, and for self-billed invoices and credit notes you receive (to be confirmed). Only domestic invoices that carry the seller's IČ DPH are reported. Regular invoices you receive are reported by the supplier's provider, not by Unimaze.

Your system must follow the delivery status of the invoices you send, and the tax reporting status of every invoice.

Sending and receiving

Unimaze is your service provider on the e-invoicing network for both directions. Your system only talks to Unimaze through MAPI, and follows each invoice through webhooks. Polling is the legacy alternative, see Polling (legacy).

Sending an invoice

sequenceDiagram
    participant E as Your system
    participant U as Unimaze
    participant B as Buyer's provider
    participant T as Tax authority

    E->>U: Submit the invoice (your messageId)
    U->>B: Send the invoice over the network
    U->>T: Report the invoice (Tax Data Document)
    B-->>U: Receipt (AP or RE)
    U-->>E: messageStatusChanged (delivered or parked)
    T-->>U: Accepted or Rejected
    U-->>E: Accepted or Rejected eMLR
    U-->>E: taxReportingStatusChanged (on acceptance)

1. Submit. Generate a message ID in your system and submit the invoice:

   • JSON: POST /api/v1/transactions/submit-invoice?messageId={messageId}&more=false
   • UBL XML: POST /api/v1/messages/create-business-transaction?messageId={messageId}&transactionGroupIdentifier=SubmitInvoice&more=false, with the XML file as the request body.

   Handle a validation failure in one of two places, depending on how you integrate. With webhooks, the submit call responds as soon as the invoice is stored, and validation follows: on failure the invoice becomes failed, and you get a messageStatusChanged event with the errors (see Outbound: ready to be sent). With polling (legacy), the submit call validates the invoice and rejects it with 422, and then nothing is created. Either way, fix the invoice and send it again.

2. Delivery. Unimaze sends the invoice over the network to the buyer's provider. The status is pendingdelivery until the buyer's provider confirms receipt:

   • An accepting receipt (AP) sets the status to delivered.
   • A rejecting receipt (RE) sets the status to parked.
   • If no receipt arrives, the invoice is set to delivered after a timeout.

   Each change is sent to you as a messageStatusChanged event. delivered, failed and parked are final. In rare cases manual handling delays the final state, see Delivery guarantees.

3. Tax reporting starts as soon as the invoice is handed over to the buyer's provider, in parallel with step 2. See Tax reporting and replies.

Receiving an invoice

sequenceDiagram
    participant S as Supplier's provider
    participant U as Unimaze
    participant T as Tax authority
    participant E as Your system

    S->>U: Invoice over the network
    opt Self-billed invoice (you are the seller)
        U->>T: Report the invoice (Tax Data Document)
    end
    U-->>E: deliveryNotified
    E->>U: Fetch the invoice
    E->>U: mark-as-delivered
    opt Self-billed invoice (you are the seller)
        T-->>U: Accepted or Rejected
        U-->>E: taxReportingStatusChanged (on acceptance)
    end

1. Arrival. The invoice arrives over the network and Unimaze validates it. By default, an invalid invoice is not delivered to your system and is not reported. Your participant can instead be set up to receive invalid invoices, marked as invalid.
2. Tax reporting. A regular invoice you receive is reported by the supplier's provider, so Unimaze doesn't report it and you get no tax reporting status for it. A self-billed invoice you receive is different: you are the seller, so Unimaze reports it for you at once, without waiting for your system to fetch it. (to be confirmed) See Tax reporting and replies.
3. Fetch. When the invoice is ready, its status is pendingdelivery and Unimaze sends your endpoint a deliveryNotified event. Fetch the invoice as JSON with GET /api/v1/transactions/submit-invoice?messageId={messageId} (or correct-with-credit for a credit note), or as XML with GET /api/v1/messages/{messageId}/documents/core.
4. Confirm. When your system has stored the invoice, call POST /api/v1/messages/{messageId}/mark-as-delivered. If it can't be imported, call mark-as-failed with an error message instead. There is no step to accept or reject the invoice.

Run a daily safety-net check for invoices that were notified but never confirmed. The steps are the same as in Receiving inbound messages.

Tax reporting and replies

In Slovakia the seller's provider reports the invoice. If your participant is set up for Slovak tax reporting, Unimaze reports each valid invoice and credit note where you are the seller: the ones you send, and the self-billed ones you receive (to be confirmed). Only domestic invoices that carry the seller's IČ DPH are reported. Unimaze sends a Tax Data Document over the network to the tax authority. (To correct a reported invoice, cancel it with a credit note and send a new invoice. See Correcting an invoice.)

Follow the outcome through webhook events. When the tax authority accepts the report, taxReportingStatus changes from none to electronic and a taxReportingStatusChanged event is sent. Its properties include actionMessageId, the message identifier of the tax report (MLA). Unimaze also delivers the tax authority's answer as a reply message (eMLR), which carries the reason when a report is rejected:

• Tax reporting doesn't change the invoice's delivery status. A buyer's RE that parks an invoice doesn't stop the reporting.
• If the tax authority never answers, no eMLR arrives.
• In rare cases the report can't be sent and needs manual handling. You then get a Rejected eMLR later.
• Unimaze also creates a separate tax message (MLA) in your account for each report. For the message formats, see Tax reporting in Slovakia.

Replies are inbound messages. They wait in pendingdelivery like any other inbound message: fetch each one with GET /api/v1/messages/{messageId}/documents/core and mark it as delivered. With legacy polling, find them with GET /api/v1/messages?status=pendingdelivery&transfer=inbound.

If your participant is set up for invoice replies (MLRs), which is off by default, you also get an MLR for each invoice you send: when it is handed over to the buyer's provider, or a Rejected MLR if delivery finally fails.

Profile types

Slovakia uses two profiles: regular billing and self billing. How you choose the profile depends on the API:

• Transaction Services (JSON): set the profileType property in the JSON for POST /api/v1/transactions/submit-invoice and POST /api/v1/transactions/correct-with-credit. Use self-billing for a self-billing invoice or credit note. Leave profileType out for regular billing. Unimaze then sets the process and document type identifiers below for you.
• Messaging Services (XML): set cbc:CustomizationID and cbc:ProfileID in the UBL document yourself, using the values below.

Regular billing

• ProfileID (process identifier):
  • urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 (scheme = cenbii-procid-ubl)
• CustomizationID:
  • urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
  • urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

Self billing

• ProfileID (process identifier):
  • urn:fdc:peppol.eu:2017:poacc:selfbilling:01:1.0 (scheme = cenbii-procid-ubl)
• CustomizationID:
  • urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0
  • urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:selfbilling:3.0

Document types

Recommended document type codes in Slovakia:

Correcting an invoice

To correct an invoice you have already sent, issue a credit note (381) that refers to the original invoice (BT-25, preceding invoice reference), then send a new invoice with a new number. The Financial Directorate of the Slovak Republic recommends this approach.

Use a new invoice number for every invoice that has been delivered and reported. If an invoice was rejected, by validation, by the buyer's provider or by the tax authority, you can send the corrected invoice with the same number, keeping the same issue date and invoice type code. See also the Slovakia FAQ.

VAT category codes

When issuing an electronic invoice under Peppol BIS Billing 3.0, the VAT category code is determined by the tax regime of the specific supply, not by the type of goods or service itself.

To determine the VAT category code, first identify the tax regime of the supply under the relevant provisions of the VAT Act. Assign the VAT category code for that regime and, for exempt or special regimes, the exemption reason code (VATEX) as well.

The basic set of codes for Slovakia is:

• S – Standard rate – a taxable supply to which the standard or a reduced VAT rate applies,
• E – Exempt from tax – a supply exempt from VAT,
• K – Intra-Community supply – an exempt intra-Community supply of goods or services,
• G – Export outside EU – an exempt export outside the EU,
• AE – Reverse charge – reverse charge of the tax liability,
• O – Not subject to VAT – a supply outside the scope of VAT,
• Z – Zero rated goods – a supply subject to an actual zero VAT rate.

VATEX use in Slovakia

The VAT category code determines the tax regime of the supply.

VATEX (VAT exemption reason code) gives the reason why a supply is exempt from VAT or subject to a special regime, where the VATEX code list has a code for that case. It is data element BT-121, which accompanies BT-120 (TaxExemptionReason), the free-text statement of the reason for the exemption or special regime.

For example, category E – Exempt from tax has several possible VATEX codes. For exemptions under Article 132 of Directive 2006/112/EC, Peppol BIS 3 distinguishes the individual exemption reasons with the codes VATEX-EU-132 through VATEX-EU-132-1Q.

Always use the official, current VATEX code list to give the reason for a VAT exemption or special regime.

Reference to the Peppol BIS 3 VATEX code list: Peppol BIS Billing 3.0 — Rules (VATEX code list). The European Commission updates the code list several times a year.

Reference to the VATEX code list for e-Invoice purposes: Registry of supporting artefacts to implement EN16931 — VATEX code list.

VATEX is a European/Peppol code list of exemption reasons, not a Slovak legislative code list — not every Slovak provision maps to its own VATEX code, and VATEX-EU-132 is a general Article 132 code with more detailed sub-codes VATEX-EU-132-1A through -1Q available for precision.