Credit note and advance invoice as an e-invoice

In short

• A credit note has type 381 (CreditNote), a debit note 383 (Invoice). Both reference the original invoice in field BT-25.
• A corrective invoice with code 384 is still being prepared for Slovakia. Until then FS recommends a credit note and a new invoice.
• An advance (proforma) invoice as a request for payment is not sent via Peppol. A tax document for a received payment is, according to FS with code 388.
• A taxed advance is deducted in the final invoice as a negative line, an untaxed one via PrepaidAmount.
• From 2027 a rent or lease payment schedule no longer replaces an invoice for each period.

Credit note: type 381 and the reference to the original invoice

According to the Financial Administration (hereinafter FS), the most common and simplest way to correct in the Peppol network is a credit note to the original invoice (Credit Note) followed by a new, correct invoice. Field BT-25 (InvoiceDocumentReference) must contain an unambiguous reference to the original invoice (FS FAQ, part I, question 50). In Peppol BIS Billing 3.0 a credit note is a separate document type 381 and the same mapping rules apply to it as to invoice 380 (FS FAQ, part II, question 17).

The VAT act also regards as an electronic invoice a document that amends the original electronic invoice and relates to it specifically and unambiguously; it must contain the sequential number of the original invoice and the data that change (§ 85o(5)). A credit note in Peppol, however, is a complete document. The explanatory memorandum to the government bill (print 1454), status on 30 September 2026 in first reading, states that EN 16931 does not allow the content of a corrective invoice to be limited to the data that change, and the bill therefore adjusts the reporting of data from corrective invoices. The bill is not yet law.

A ready-made credit note is in sample 08: root element CreditNote with code 381, the number and date of the original invoice in cac:BillingReference (BT-25, BT-26) and positive amounts.

Debit note: type 383

A debit note that increases the tax base can be issued in Peppol BIS Billing 3.0 with code 383 (Debit note) from code list UNCL1001. The link to the original invoice is given in the same way via BT-25 (FS FAQ, part II, question 39). See sample 09: root element Invoice with code 383 and the reference in cac:BillingReference, otherwise like an ordinary invoice, including the due date.

Corrective invoice with code 384: not yet

FS currently recommends handling corrections with the combination of a credit note and a new invoice. Together with OpenPeppol it is preparing the introduction of code 384 (corrective invoice), similar to Germany. The intention is to use it in cases without an effect on VAT or the price, while for cases with an effect on VAT or the price the credit note and new invoice remain. According to FS, the inclusion of code 384 is realistic within the autumn 2026 release of Peppol BIS Billing 3.0 (FS FAQ, part II, question 30). As an alternative FS also mentions a corrective invoice with all mandatory particulars and the reference in BT-25 (FS FAQ, part I, question 50).

One corrective invoice for several invoices

If the event decisive for correcting the tax base occurred on the last day of the settlement period, you may issue one corrective invoice for several repeated supplies. Field BT-25 can be repeated, so each number of an original invoice is given in a separate entry, not separated by a character in one field. All corrected invoices must be stated. The period to which the correction relates is not a mandatory particular; the date of issue of the original invoice may be stated, but need not be (FS FAQ, part II, question 49).

Advance invoice versus tax document for a received payment

Here lies the biggest difference between two documents that in practice are both called an “advance invoice” (FS FAQ, part I, question 34):

• A proforma invoice or request for payment does not have the particulars of an invoice under the VAT act and its issue does not give rise to a tax liability. It is not an invoice within the meaning of the VAT act and is not sent through the e-invoicing system.
• An invoice for a received payment arises when you receive a payment before the supply of goods or services (§ 72(1)). It has the character of a tax document, is subject to the electronic invoice regime and is sent through the delivery service.

From 1 January 2027 a domestic VAT payer must issue an electronic invoice for a payment it receives before the supply of goods or services in Slovakia from a domestic taxable person or a domestic non-taxable legal person (FS FAQ, part I, question 38; § 85o(2)). The deadline is 15 days from the day the payment is received (§ 85o(6)(b)), as FS also states (FS FAQ, part I, question 74). The act regulates it specifically for the electronic invoice: under § 85o(1), § 71 to 76 apply only where paragraphs 2 to 8 and 15 do not provide otherwise. Do not therefore rely, for an e-invoice, on the option of issuing the invoice by the end of the month in which the payment was received under § 73(1)(b).

On the document type FS answers directly: for a tax document for a received payment, code 388 (Tax invoice) from code list UNCL1001 is used (FS FAQ, part II, question 22). The structure of such a document (one line with a rate, PrepaidAmount equal to the whole amount and PayableAmount 0) is shown in sample 12, which uses precisely code 388.

Deducting the advance in the final invoice

FS distinguishes whether you issued a tax document for the advance (FS FAQ, part II, question 38):

• Taxed advance (you issued an invoice for the received payment): the deduction is not given in AllowanceCharge but as a negative line in cac:InvoiceLine with quantity -1. The line contains the tax base and the VAT at the rate from the original tax document, so it reduces the VAT summary. The link to the tax document is given via BillingReference / InvoiceDocumentReference (BT-25).
• Untaxed advance (no tax document arose): this is neither a correction of the tax base nor of VAT. You state the amount as PrepaidAmount (BT-113), which only reduces the amount payable. A negative line with VAT is not used here.

That advances already paid are as standard stated in PrepaidAmount is confirmed by FS also for settlement invoices (FS FAQ, part II, question 26). Both situations on one document are shown in sample 10: a negative line with quantity -1 for the taxed advance, the link to the tax document via BillingReference (BT-25) and the untaxed advance in PrepaidAmount.

Rent, leasing and payment schedules

If a VAT payer is obliged from 1 January 2027 to issue an electronic invoice, it can no longer use a rent payment agreement (payment schedule) as a summary invoice under § 75(2). It issues an electronic invoice for each repeatedly supplied rental service (FS FAQ, part I, questions 33 and 51). This also applies to lease instalments if the lease is a supply of services. A summary electronic invoice may be issued only for supplies during at most one calendar month, within fifteen days of its end (§ 85o(7); FS FAQ, part II, question 41).

An electronic invoice need not be issued if the supply is exempt from tax under § 28 to 43 and 47, for example for a lease of real estate exempt under § 38(3) (FS FAQ, part I, question 51).

Corrections of 2026 invoices

A document that, in the period from 1 January 2027 to 30 June 2030, amends an invoice for a supply made by 31 December 2026 is, under § 85o(23), subject to the same conditions as the original invoice. If the original invoice was electronic and sent through the delivery service already in 2026, the correction must meet the same conditions and go through the delivery service too.

The government bill (print 1454), status on 30 September 2026 in first reading, proposes softening this rule (after renumbering as § 85o(22)): the same conditions as for the original invoice “may” be applied. According to the explanatory memorandum, for a paper invoice from 2026 the supplier could choose a paper or an electronic correction, and for an electronic invoice that did not go through the delivery service it could send the correction through the delivery service as well. The bill is not yet law. Further mandatory data of the document are summarised in the article on the mandatory particulars of an e-invoice, the technical framework in the article on Peppol BIS Billing 3.0.

Frequently asked questions