hr.device_missing_isu

HTTP 400   type: validation_error   param: device_id | register_mark

{
  "error": {
    "type": "validation_error",
    "code": "hr.device_missing_isu",
    "message": "Device VM-0043 has no ISU number assigned. Register the premises in ePorezna and add the ISU number before fiscalizing.",
    "param": "device_id",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.device_missing_isu"
  }
}

What happened

The device you fiscalized against has no ISU number — the self-service device identifier, ISU broj, sent to the Tax Administration as OznNapUr. Its isu_status is pending.

Every unattended sale must carry one. Without it, the message is incomplete and the sale cannot be reported.

FiskHub blocks the request here, before anything is signed or sent, so you get this error rather than an opaque rejection from upstream. Nothing was fiscalized and no receipt number was allocated.

On an attended receipt this is a different problem

OznNapUr carries two different things. On an unattended sale it is the ISU number, which only the Tax Administration can issue. On an attended receipt it is the cash register’s own mark — a number you choose, unique within the business premises, that nobody has to register for you.

So an attended receipt never needs an ISU number, and this code with param: "register_mark" means something entirely fixable: send register_mark, or set one in the device’s or company’s configuration. Everything below is about the unattended case.

Should you retry?

No. The same request will fail identically until the device has an ISU number. Retrying is not a workaround and there is no parameter that skips this check.

The fix

The ISU number cannot be automated. Not by us, not by anyone.

It is issued by the Tax Administration when the business premises is registered in ePorezna. Premises registration has been done through ePorezna, not the fiscalization web service, since 1 July 2017 — the service exposes only working-hours changes, and only since 1 January 2026.

FiskHub cannot generate an ISU number, request one, look one up, or derive one from anything. Neither can any other integrator. There is no API for it and none is planned. A number invented locally is not an ISU number and will be rejected.

1. Register the business premises in ePorezna, if it is not registered already. This is done by the taxpayer or their accountant, in the Tax Administration’s own application.

2. Receive the ISU number the Tax Administration assigns to the self-service device at that premises.

3. Enter it in FiskHub. Either:

   curl -sS -X PATCH \
     "https://api.fiskhub.com/v1/devices/b74a1c33-8e2f-4d05-91a6-3c7b5e0d2f18" \
     -H "Authorization: Bearer $FISKHUB_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{ "isu_number": "43" }'

   or, for a batch of premises registered together, use the CSV import:

   label,premises_code,isu_number
   VM-0043,POSL1,43
   VM-0044,POSL1,44

4. Fiscalize again. The device’s isu_status becomes assigned and it works from the next request onwards.

The number is digits with no leading zeros, and it identifies exactly one device — sharing one across two machines produces a fiscal record neither of them matches.

Finding every affected device before it costs you a sale

curl -sS -G https://api.fiskhub.com/v1/devices \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  --data-urlencode "isu_status=pending"

Run this as part of commissioning a site. A device that reaches the field without an ISU number fails at its first sale, in front of a customer, which is the most expensive place to discover it.

isu_status: "mismatch"

A device can also be blocked with isu_status: "mismatch", meaning the Tax Administration rejected the number we hold. The fix is the same shape: re-check the number in ePorezna and correct it here. Do not guess — a plausible-looking wrong number produces receipts filed against the wrong device.