hr.certificate_oib_mismatch

HTTP 400   type: validation_error   param: file (uploading) or device_id (fiscalizing)

{
  "error": {
    "type": "validation_error",
    "code": "hr.certificate_oib_mismatch",
    "message": "The certificate is issued to OIB 25089460814 but company Druga d.o.o. has OIB 12345678903. Certificates are per company — upload the one belonging to this OIB.",
    "param": "file",
    "upstream": { "code": "s005", "message": "OIB iz poruke nije jednak OIB-u iz certifikata." },
    "doc_url": "https://docs.fiskhub.com/errors/hr.certificate_oib_mismatch"
  }
}

What happened

The OIB in the certificate’s subject is not the OIB of the company it was uploaded for, or of the company whose sale was being signed.

The Croatian Tax Administration rejects any message whose payload OIB differs from the signing certificate’s OIB — their error s005. FiskHub checks this at upload time so the mismatch surfaces during configuration rather than in front of a customer.

Nothing was fiscalized.

Should you retry?

No. The certificate and the company will never match.

The fix

At upload

Upload the certificate belonging to that company’s OIB. Check which OIB the certificate carries:

openssl pkcs12 -in fiskal1.p12 -nokeys -legacy | openssl x509 -noout -subject

The subject contains the OIB, usually as HR<OIB> in the serial number or organisation identifier. Compare it with the company:

curl -sS https://api.fiskhub.com/v1/companies \
  -H "Authorization: Bearer $FISKHUB_API_KEY"

They must be equal. If the certificate is right and the company’s OIB is wrong, the company was created with a typo — and oib cannot be patched, because the fiscal history is keyed on it. Create the company correctly and move its devices across.

At fiscalization

Seeing this on a sale means the company’s stored certificate no longer matches its OIB. Upload the correct one:

curl -sS -X POST https://api.fiskhub.com/v1/certificates \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  -F "company_id=3a5f2b18-7c4d-4e91-9a2b-6d8e0f1c3a57" \
  -F "[email protected];type=application/x-pkcs12" \
  -F "passphrase=$P12_PASSPHRASE"

Then retry the affected invoices:

curl -sS -X POST \
  "https://api.fiskhub.com/v1/invoices/inv_01J9Z4T7M2K8Q6R3V5X1Y0B2C4/retry" \
  -H "Authorization: Bearer $FISKHUB_API_KEY"

Why there is one certificate per company

This constraint is what makes certificates a company-level object rather than a tenant-level one.

A tenant with three companies has three OIBs and needs three certificates. There is no shared certificate, no fallback and no inheritance: loading company A’s certificate to sign company B’s invoice is exactly what s005 exists to catch, and FiskHub makes it impossible rather than merely unlikely.