e-Faktura API

Document lifecycle

Status

Every EInvoice and InboxDocument carries a stable public status, mapped from the engine’s internal state and UJP’s own status code:

Status	Meaning
`validating`	Queued, not yet built.
`invalid`	Failed validation — see `problems`.
`awaiting_signature`	Waiting on your signing agent (Merot Bridge or an SDK signing worker).
`queued`	Validated and signed, waiting for a submission slot or a UJP outage to clear.
`submitting`	A submission attempt is open.
`held`	UJP outage — queued for resubmission within the legal window.
`delivered`	UJP status `01` — sent, awaiting the buyer’s decision.
`accepted`	UJP status `03` — the buyer explicitly accepted it.
`auto_accepted`	UJP status `04` — silence past the deadline; UJP treats this as acceptance.
`rejected`	UJP status `05`.
`cancelled_by_storno`	UJP status `07`.
`corrected`	UJP status `09`.
`registered`	UJP status `10`.
`draft_at_ujp`	UJP status `00`.
`failed`	Terminal error — see `problems`.

GET /v1/einvoices/{id}/status-history returns the ordered trail of every status event.

The inbound accept/reject deadline

An incoming e-invoice must be accepted or rejected by the 10th of the month after its transaction date. If you do nothing, UJP treats silence as acceptance (auto_accepted). InboxDocument.decideBy is that deadline (inclusive) and daysLeft counts down to it — subscribe to the inbox.deadline_approaching webhook (fired at 5, 2 and 1 days left) instead of polling.

POST /v1/inbox/{id}/accept
POST /v1/inbox/{id}/reject   { "reasonCode": "O-3", "comment": "Goods not received" }

Accepting needs no reason; rejecting needs a reason code from UJP’s reject-reason codebook (O-1…O-7). Past the deadline, both return 409 decision_deadline_passed — the invoice is already auto-accepted.

UJP has not confirmed this yet

Whether the 10th-of-month deadline itself moves when it falls on a weekend or public holiday is not yet confirmed by UJP. Merot’s implementation currently does not shift it — check the changelog for updates once UJP clarifies.

Storno and correction

Both create a new document referencing the original by EUID — the original is never mutated.

Storno (POST /v1/einvoices/{id}/storno) — a full void: docStorno: 1, a void reason from UJP’s codebook (S-x), negated line amounts. Allowed only from delivered, accepted or auto_accepted.
Correction (POST /v1/einvoices/{id}/correction) — a full replacement: docStorno: 2, a correction reason (C0x) and the complete replacement document.

Both are blocked with 409 period_closed once the company’s annual account has been filed for that year (you set annualAccountFiledFor on the company once your accountant files it — Merot has no other way to know).

Submission to UJP

Unlike the Payroll API, which generates files for you to upload to UJP yourself, the e-Faktura API submits the document to UJP for you — that is its whole purpose. What it never does is hold your signing key: every document is signed on your own device (Merot Bridge) or your own server (an SDK signing worker) before Merot relays it to UJP. See Signing: Mode A vs Mode B.