Skip to content
FiskHub

upstream_signature_invalid

Carried inside a 200 invoice body as `fiscal_error`. NOT an HTTP error.
{
  "fiscal_error": {
    "code": "upstream_signature_invalid",
    "message": "The Tax Administration's response signature did not verify, so the JIR cannot be trusted. Contact support.",
    "retry_scheduled": false
  }
}

What happened

A response came back, but its XML signature did not verify against the Tax Administration’s signing certificate. FiskHub therefore discarded whatever JIR it contained and marked the invoice failed.

An unverified response is not proof of fiscalization. Accepting a JIR we cannot authenticate would mean recording a receipt as confirmed on the word of something that might not be the Tax Administration at all. The invoice stays unconfirmed instead, which is the honest state.

Plausible causes, roughly in order of likelihood:

  • The Tax Administration rotated its signing certificate and our trust store is behind.
  • A middlebox — a proxy, a TLS-inspecting firewall — altered the response in transit.
  • A defect in our signature verification.

Should you retry?

No. retry_scheduled is false, and the sweep leaves it alone. If verification is failing for a systemic reason, every retry fails the same way.

The fix

Contact support, quoting the invoice id and your X-Request-Id. This one is ours: nothing in your request causes it and nothing you can change fixes it.

While it is being investigated:

  • Keep selling. Every sale still gets a ZKI and a compliant receipt.

  • Watch for a pattern. One occurrence is worth reporting; a run of them across devices means something changed upstream and is urgent.

    Terminal window
    curl -sS -G "https://api.fiskhub.com/v1/invoices" \
      -H "Authorization: Bearer $FISKHUB_API_KEY" \
      --data-urlencode "status=failed" \
      --data-urlencode "from=2026-08-27T00:00:00+02:00"

  • Do not disable verification. There is no setting for it, and there will not be. An unverified JIR is not evidence of anything.

Once the cause is resolved, affected invoices are retried with POST /v1/invoices/{id}/retry and confirm normally, provided they are still inside their 30-day window.