hr.total_mismatch

HTTP 400   type: validation_error   param: total

{
  "error": {
    "type": "validation_error",
    "code": "hr.total_mismatch",
    "message": "This receipt totals -12.50, but everything it declares adds up to 12.50 — the same figure with the opposite sign. A storno reverses every part of the receipt, not only the total: negate the base and the tax as well.",
    "param": "total",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.total_mismatch"
  }
}

upstream is null. The Tax Administration checks no arithmetic and would issue a JIR for this.

What happened

The parts of the receipt do not account for total.

This is the companion to hr.tax_line_inconsistent, and neither ships without the other. That one asks whether a line’s amount fits its own base. This one asks whether those figures describe the receipt at all. A check that does only the first reads as coverage while passing this:

{ "total": "-12.50", "vat": [{ "rate": "25.00", "base": "10.00", "amount": "2.50" }] }

25% of 10.00 is 2.50. The line is perfect. It is also the wrong sign for the receipt it is on.

What has to add up

Σ(vat.base + vat.amount)
  + Σ(consumption_tax.amount)
  + vat_exempt_amount + margin_amount + non_taxable_amount
  + Σ(fees.amount)
  == total

consumption_tax.base is not in that sum. Consumption tax is levied on the same net amount VAT is, so counting its base again would count the goods twice. A hospitality receipt of 100.00 net is 100.00 + 25.00 + 3.00 = 128.00, not 228.00.

The tolerance is 0.02, or 1% of the total, whichever is larger — enough for the cent of rounding that several rates can produce between them.

The storno case

By far the commonest cause, and the message names it outright when the declared parts are the total with the sign flipped.

A storno reverses every part of the receipt, not only IznosUkupno:

// Wrong — only the total was negated
{ "total": "-12.50", "vat": [{ "rate": "25.00", "base": "10.00",  "amount": "2.50"  }] }

// Right
{ "total": "-12.50", "vat": [{ "rate": "25.00", "base": "-10.00", "amount": "-2.50" }] }

Fees negate too. A deposit collected on the original is returned on its reversal, so "0.10" becomes "-0.10". A fee configured on the device or the company is turned around for you; a fee sent on the request is left exactly as you sent it, because only you know whether it was a collection or a return.

When the check does not run

A receipt carrying other_taxes. OstaliPor has its own Osnovica, and the specification never says whether that base is the same net amount or a separate portion of the receipt. Both readings are defensible and they give different totals, so either would refuse correct receipts. The per-line check still applies; the total is left to your own arithmetic.

A receipt declaring no tax components at all. There is nothing to sum. A VAT-registered company filing no VAT is a different problem — see companies on default_vat_rate.

Should you retry?

Not unchanged. Fix the amounts first.

Let us compute it for you

Send no vat at all and set default_vat_rate on the company. The total is split for you — including on a storno, where the base and the tax come back negative — and fees, exempt, margin and non-taxable amounts are taken out of the base before the split. The parts then account for the total by construction.