invoice_already_exists

HTTP 409   type: conflict   param: number

{
  "error": {
    "type": "conflict",
    "code": "invoice_already_exists",
    "message": "Receipt 1042 at selling point POSL1 has already been submitted for this device and year. It is confirmed with JIR 8b31c705-1f4a-49de-bc0a-2f6e5d7a9c14. A sale is never fiscalized twice.",
    "param": "number",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/invoice_already_exists"
  }
}

What happened

You supplied a number that has already been used for this business key:

oib | oznPosPr | isuNumber | brOznRac | year

That combination is what the Tax Administration records as the identity of a receipt, and it is unique. Nothing was fiscalized, nothing was signed, and the existing invoice is untouched — the request was refused before any of that.

This error is only reachable when you supply number yourself. If you omit it, FiskHub allocates the next free number for that selling point and year and the collision cannot occur.

Should you retry?

Not as sent. The number is taken. Find out what happened to the original first.

The fix

Check what the existing invoice is

The message names its status and JIR. To see the record:

curl -sS -G "https://api.fiskhub.com/v1/invoices" \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  --data-urlencode "device_id=6f1c0f9e-2b7a-4a56-9d3e-1f0b8a4c7d21" \
  --data-urlencode "from=2026-08-27T00:00:00+02:00"

• It is your sale, already filed. Nothing to do. Print from the stored invoice — the JIR, the ZKI and the QR payload are all on it. This is what a retry that lost its response looks like, and the sale is fine.
• It is a different sale. Your counter has gone backwards, or two devices are sharing one. Advance the counter past the highest number filed at that selling point this year and send again with a fresh Idempotency-Key.

Then decide who owns the sequence

The usual cause is one counter shared across several selling points, or a counter that reset after a restart or a redeployment. Croatian unattended receipts use OznSlijed = P: the sequence belongs to the business premises and restarts each calendar year. Two selling points both issuing a receipt 1 is correct — one selling point issuing 1042 twice is not.

If keeping a durable per-premises counter is awkward, stop sending number. FiskHub allocates it inside the transaction that stores the invoice, so it cannot race, gap or repeat.

Not the same as an idempotency conflict

	idempotency_key_reused	invoice_already_exists
Detected by	The Idempotency-Key store	The invoice business key
Means	The same key was sent with a different body	The same receipt number was already filed
Window	24 hours	The whole calendar year
Fix	Use a new key per sale	Advance the counter, or stop supplying one

A replay with the same key and the same body is neither error: it returns the original response with Idempotent-Replayed: true. See idempotency.