Skip to content
FiskHub

hr.invalid_receipt_number

HTTP 400   type: validation_error   param: number (or null)
{
  "error": {
    "type": "validation_error",
    "code": "hr.invalid_receipt_number",
    "message": "Receipt number \"007\" must be digits with no leading zeros and cannot be 0 (restrictive error 178).",
    "param": "number",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.invalid_receipt_number"
  }
}

What happened

The receipt number (BrOznRac) for this sale failed validation. Croatian restrictive error 178 rejects a receipt number of 0, and the number must be digits with no leading zeros.

Nothing was fiscalized.

There are two ways to get here, and param tells them apart.

param: "number" — you supplied it

POST /v1/invoices accepts an optional number. If you send one, it must match ^[1-9][0-9]{0,19}$: digits only, no leading zeros, not 0, at most 20 digits.

Common causes:

  • A zero-padded counter. "0042" is rejected; send "42".
  • A number formatted for display. "1042/1/1" is the receipt label, not BrOznRac. The premises and device parts are already carried by the premises code and the ISU number.
  • A JSON number instead of a string. Send "1042", not 1042.
  • A counter that started at zero. Croatian receipt sequences start at 1.

param: null — FiskHub allocated it

If you omitted number, the value came from our allocation, and an invalid one is a defect on our side. Contact support quoting your X-Request-Id and the device_id; there is nothing to change in your request.

Should you retry?

If you supplied the number: fix the format and send it again. Retrying it unchanged cannot succeed. Use the same Idempotency-Key only if the body is otherwise identical — a corrected number is a different body, so use a fresh key.

If we allocated it: once, then stop. A transient allocation problem may clear; a systematic one will not, and the sequence for that premises needs fixing before any sale there succeeds.

The fix

Send a number in the accepted form, or omit number entirely and let FiskHub allocate it. Whichever you choose, keep the sale: it was never fiscalized, so store it locally with its real occurred_at and submit it once corrected. FiskHub marks the late submission automatically, and there are 30 days — but not more.

Why the number is per selling point

With OznSlijed = P, which is what unattended fiscalization sends, the receipt sequence belongs to the business premises and restarts each calendar year. Two selling points both issuing a receipt 1 is correct, so a receipt number can never be a global identifier. What is unique is the business key oib | oznPosPr | isuNumber | brOznRac | year.

If you keep the sequence, keep one counter per selling point. If you would rather not, omit number: FiskHub allocates and inserts in a single transaction, which is what stops two devices at the same premises from being handed the same number when they sell in the same moment. A duplicate or a gap in a fiscal receipt sequence is a compliance problem discovered by an auditor rather than by a test.

Reusing a number that has already been filed at that selling point is a different error — 409 invoice_already_exists, from the business key rather than from the format check.