E-invoicing guide

E-invoice requirements from 2027

An electronic invoice is not a PDF; it is a structured document with precisely defined fields. We summarise what it must contain to pass validation and be deliverable via Peppol.

Updated: September 2026

E-invoice ≠ PDF

The statutory e-invoice from 2027 is a structured data document (XML according to the EN 16931 standard, Peppol BIS Billing 3.0 profile), not a scan or a PDF attached to an e-mail. Thanks to the fixed structure, both the other party and the Financial Administration process it by machine, which is why the fields are mandatory and type-checked. A nice PDF for reading can be generated from the invoice at any time; what matters, however, are the data.

Mandatory requirements

Put simply, every e-invoice must contain:

  • Identification of the document: invoice number, date of issue, due date and the date of supply. The date of supply is mandatory when it differs from the date of issue (§ 74 of the VAT act). It determines which VAT period the document belongs to, and the 15-day deadline for issuing the invoice runs from it (§ 73 of the VAT act); the e-invoice itself then has to be sent within 15 days of issue. In UBL (the XML format of the e-invoice) it is given as cac:Delivery/cbc:ActualDeliveryDate (BT-72).
  • Document type: invoice (code 380), credit note (381) or corrective invoice (384). An advance (pro forma) invoice is not a tax document and does not travel via Peppol as a tax invoice.
  • Supplier and customer: business name, address, IČO/DIČ and IČ DPH (VAT ID), and the electronic address in the network (Peppol ID, for Slovak entities in the form 0245:DIČ; see Peppol ID).
  • Currency of the document (e.g. EUR).
  • Invoice lines: item name, quantity, unit price and the net amount per line.
  • VAT breakdown: for each rate the taxable amount and the tax amount, with the VAT category (e.g. standard, reduced, exempt, reverse charge).
  • Document totals: total without tax, total tax and amount due; these must agree mathematically with the lines and the breakdown.
  • Payment details: usually the IBAN and the variable symbol / payment reference. The payment reference belongs in the field cbc:PaymentID (BT-83); note that the standard allows only one such reference on an invoice (rule UBL-SR-44). If you need to carry several symbols at once, the payer reference notation in a single field is used (e.g. /VS…/SS…/KS…), which Slovak accounting systems agree on in practice.

Where e-invoices most often “fail”

Validation (a check against EN 16931 and the Peppol rules) rejects a document that does not add up. Typical causes:

  • Totals that do not match: the declared totals do not correspond to the sum of the lines and the VAT breakdown (the most common cause is rounding).
  • Wrong VAT category or rate: e.g. an exempt supply marked as the standard rate, or a missing exemption reason.
  • Incomplete identification of a party: a missing IČ DPH where it is mandatory, or a wrong Peppol ID.
  • Wrong Peppol ID format: 0245:SK… instead of 0245: + the digits of the DIČ.

A detailed analysis, including how to avoid the errors, is in the article the most common e-invoicing errors. The technical details of the fields (BT/BG codes) are discussed in the article on Peppol BIS Billing 3.0.

How you do not have to remember it

In practice you do not fill in these fields by hand in XML. The portal (or your accounting/e-shop solution via an integration) builds the document correctly and validates it before sending, so only a technically valid invoice goes into the network. Receiving such invoices is free with us without the archive (up to 1,000 a month), with the Data archive from €2 per month per IČO.

Be ready for the mandate on time

Verteco runs its own Slovak Peppol Access Point, certified by the Slovak Financial Administration. Receiving without the archive is free up to 1,000 invoices a month, and you can start in a few minutes.