Repairs

How do I correct an e-invoice that has already been delivered?

Short answer

First determine the invoice status. If it has not yet been sent, or was rejected technically, correct the XML and submit the valid version under the system rules. If it was successfully delivered and accepted as an accounting document, do not overwrite the original. Correct errors in the amount, VAT, quantity, customer or supplied item through the appropriate corrective document, credit note, debit note or replacement invoice.

Before dispatch

XML fix

The error can be corrected before the delivered document is created.

Technical rejection

Resubmission

After correcting the validation or identifier, the correct document will be sent.

Delivered

Reference document

Material errors are resolved by formal correction.

Audit trail

Link to the original document

The original invoice, repair and communication are kept.

Detailed explanation

An electronic invoice is not a draft document that can be quietly amended by the sender after delivery. If the XML were to be altered without reference to the original document, the sender, recipient and accounts department could end up with different versions of the same invoice. It is therefore crucial to distinguish between a technical error prior to delivery, a technical rejection, a commercial disagreement and a correction to a tax document. In the case of a factual error, there must be a demonstrable link to the original invoice.

As set out in the law and technical rules

Corrections to the tax base and corrections to documents must be assessed primarily in accordance with Section 25 and the invoicing rules in Section 71 et seq. of the VAT Act. The content of the invoice is governed by Section 74. The electronic form and delivery under Section 76a do not alter the need to maintain an audit trail and accounting verifiability.

Practical examples

An incorrect EndpointID is detected before dispatch. The XML is corrected and the first correct version is sent.
The invoice was received, but the quantity should have been 80 instead of 100 items. A corrective document is issued in accordance with the outcome of the agreement.
The supplier has issued the invoice to the wrong person. Depending on the circumstances, it is necessary to consider cancelling, correcting or issuing a new invoice.

Common misconceptions

“I’ll just overwrite the XML I’ve sent.” No. An audit trail must be maintained after delivery.
“Every error means a credit note.” No. It depends on the status of the invoice and the type of error.
“A technical rejection is the same as a commercial rejection.” No. These are different situations.

Conclusion

Before dispatch, correct the data; after delivery, use a traceable accounting and tax correction linked to the original invoice.

Legal and technical basis

Act No. 222/2004 Coll. on VAT, Section 25
Act No. 222/2004 Coll. on VAT, Section 71 et seq.
Act No. 222/2004 Coll. on VAT, Section 74
Act No. 222/2004 Coll. on VAT, Section 76a
Act No. 431/2002 Coll. on accounting

Official cases from the Slovak Financial Administration’s FAQs

The following questions and answers are taken from the current July FAQ from the Financial Administration and have been assigned to this topic. Grouping the cases prevents the creation of duplicate pages, whilst retaining the full answer and the exact wording of the question.

Example 11: Can an electronic invoice be cancelled after it has been sent? How are errors in electronic invoices corrected?

Common approaches to handling errors in electronic invoices: • Validation errors: many electronic invoicing systems carry out automatic validation checks before sending, flagging format or data errors for immediate correction. • Rejected invoices: entities may reject non-compliant electronic invoices and require the sender to issue a corrected version with a reference to the original. • Corrections after dispatch: corrections to errors detected after successful dispatch usually require formal credit notes and new, corrected invoices, rather than a simple amendment to the original. • Invoice rejection: if the recipient does not accept an invoice, they must contact the issuer directly; it is not possible to reject an invoice via Peppol. Error prevention mechanisms: • Structured formats such as UBL and the Peppol network significantly reduce the likelihood of errors through standardisation. • Automated data validation helps ensure compliance with Slovak electronic invoicing requirements. System integration is designed to reduce errors arising from manual data entry

Example No. 50: Corrective invoice: What is the procedure if an invoice that has already been issued needs to be corrected via the Peppol network?

The most common and simplest procedure in the Peppol environment is to issue a credit note for the original invoice and then send a new, correct invoice. Alternatively, it is possible to send a corrected invoice, which must contain all the mandatory details in accordance with Peppol BIS Billing 3.0 in order to pass the network’s validation rules. At the same time, it must contain the corrected details, and the BT-25 field (InvoiceDocumentReference) must include a unique reference to the original invoice.

Example No. 30: Corrected invoice (document code 384 within Peppol BIS): Does the Slovak Financial Administration plan to introduce the use of document code 384 (corrected invoice) within Peppol BIS Billing 3.0, and what is the expected procedure and timeframe for its implementation?

The Slovak Financial Administration currently recommends using standard document types for invoice corrections within Peppol BIS Billing 3.0, i.e. a combination of a credit note and a new invoice. At the same time, the Slovak Financial Administration, in cooperation with OpenPeppol, is currently preparing to introduce code 384 (corrective invoice) so that it can be used within the Slovak Republic, similar to how it is implemented in Germany. The intention is to use a corrective invoice (document code 384) in cases that do not affect VAT or the price, and to use a credit note and a new invoice in cases that do affect VAT or the price. The introduction of document type code 384 is expected to take place as part of the Peppol BIS Billing 3.0 release – autumn 2026.

Primary source: Financial Administration of the Slovak Republic, FAQ 9/VAT/2025/IM k e-invoice, July 2026 update. Processed and checked on 13 July 2026.