Idempotency

How should idempotency be implemented for e-invoice submission?

⚠ Machine-translated answer, not yet manually reviewed. For the exact wording, see the Slovak original.

Short answer

Use an idempotency key linked to the invoice, XML version and submission attempt. If the same request is repeated after a timeout or retry, the system should recognise it and avoid creating a second submission. Idempotency is an operational safeguard against duplicates.

Key

Unique key

Bind it to the document and the XML version.

Retros

No duplication

A repeated request should not create a second submission.

Change

New XML

Changed content needs a new record and reason.

Audit

The result of the attempt

Save whether it was a new or repeated request.

Detailed explanation

The idempotency key can be derived from the internal invoiceId, the invoice number, the export version and the XML hash. It is important to determine what constitutes the same attempt and what constitutes a new version of the document. If the XML changes, a new context and a clear audit trail must be created.

As set out in the Act

A verifiable process must be able to distinguish between a repeated technical attempt and a new or corrected document. Without this, there is a risk of duplicate delivery and incorrect accounting processing.

Practical examples

  • A timeout triggers a retry with the same key, and the API returns the original submissionId.
  • If the user clicks ‘Submit’ twice, the second attempt is flagged as a duplicate request.
  • Once the amount has been corrected, a new hash is generated and the system requires a new approval step.

Most common mistakes

  • “Idempotence is just a technical detail.” In the case of invoices, it protects against business duplication.
  • “The key can simply be the invoice number.” With versions and corrections, this may not be sufficient.
  • “I can ignore a duplicate request without logging it.” Even ignoring a request should be logged.

Conclusion

Idempotency is an essential practical safeguard for e-invoice API submission; it prevents an uncertain retry from becoming a duplicate delivery.

Legal basis

  • Act No. 431/2002 Coll. on accounting
  • Act No. 222/2004 Coll. on VAT
  • Internal rules of document integrity

Related questions

This is not legal advice. Sources: Act No. 222/2004 Coll. on VAT, Slovak Financial Administration e-invoicing FAQ, OpenPeppol BIS Billing 3.0 and the Slovak e-Invoicing Centre’s internal validation model. Verified on 7 July 2026.