hr.sale_older_than_30_days

HTTP 400   type: validation_error   param: occurred_at

{
  "error": {
    "type": "validation_error",
    "code": "hr.sale_older_than_30_days",
    "message": "occurred_at is 2026-07-01T09:12:30+02:00, which is 57 days ago. Croatian fiscalization rejects sales older than 30 days (restrictive error 176) and this cannot be worked around.",
    "param": "occurred_at",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.sale_older_than_30_days"
  }
}

What happened

occurred_at is more than 30 days in the past. Croatian restrictive error 176 rejects such a sale outright, and since 1 January 2026 that rejection is permanent — there is no late-delivery path once the window closes.

FiskHub checks this locally, before sending, because the answer is already known and a clear error is more useful than an opaque upstream rejection.

This is a hard, legal deadline

There is no override, no support ticket that reopens the window, and no parameter that skips the check. Thirty days after the sale, that sale is permanently unfiscalizable.

Should you retry?

No. Time only moves in one direction and the sale is already outside the window.

The fix

There is no fix for a sale already past the deadline. What there is:

1. Do not change occurred_at to something recent. Backdating in the other direction — reporting an old sale as if it happened today — puts a fiscal record on file that contradicts the receipt the customer holds. That is a worse problem than the one you started with.
2. Tell the operator. They need to raise it with their accountant; how an unfiscalizable sale is handled is an accounting question, not an API one.
3. Fix the cause, so the next one does not age out.

Why this is the error that bites unattended devices

Machines go offline for weeks: a dead SIM, a site with poor coverage, a seasonal shutdown, a power fault at a premises nobody visits. Sales pile up locally, and every one of them is running its own 30-day clock from the moment it happened.

If a machine is offline for five weeks, its earliest stored sales are already unrecoverable when it reconnects — before anyone has looked at anything.

Three habits prevent it:

• Send the real occurred_at. Never the upload time. The clock started at the sale.
• Upload backlogs immediately on reconnect. Not at the end of the season, not in the nightly batch — as soon as the device has a network.
• Alert on devices that go quiet. last_seen_at on GET /v1/devices is the cheapest signal available. A machine that has not called in for a week is worth a visit long before it is worth a compliance incident.

Invoices already inside FiskHub

A sale that reached us before the deadline is FiskHub’s problem, not yours. It carries a deadline_at of occurred_at plus 30 days, the retry sweep works it deadline-first, and escalation runs at day 21 (dashboard), day 25 (email) and day 28 (prominent alert).

If one still crosses the line it becomes expired — a terminal status, kept permanently as a record, and reported as a compliance incident.

Find anything approaching the edge:

curl -sS -G "https://api.fiskhub.com/v1/invoices" \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  --data-urlencode "status=retrying"

Sort the result by deadline_at. The closest one is the one that matters.