# Document states

URL: https://postman.slovakodata.com/developers/en/stavy/
Updated: 2026-10-01

Outbound and inbound invoice lifecycle and what to do at each state.

Every transition can be delivered as a webhook.

### Outbound invoice

<div class="lifecycle">
  <span class="lc">PENDING</span><span class="lc-arr">→</span>
  <span class="lc">VALIDATING</span><span class="lc-arr">→</span>
  <span class="lc">READY</span><span class="lc-arr">→</span>
  <span class="lc">SENDING</span><span class="lc-arr">→</span>
  <span class="lc">DELIVERED</span><span class="lc-arr">→</span>
  <span class="lc lc-final">ACCEPTED</span>
</div>

`READY` means the invoice passed validation and is waiting to be sent. `SENDING`
is set right before the AS4 transmission — from that moment the invoice can no
longer be cancelled.

After sending, we distinguish two confirmations from the recipient's access point:

| State | Confirmation | What it means |
|---|---|---|
| `DELIVERED` | positive AS4 receipt | The recipient's access point received the message. The invoice has been **sent** to that access point, which has not yet processed or validated it. The credit is still only reserved. |
| `ACCEPTED` | positive MLS message | The recipient's access point processed the invoice — it is **delivered** in the Peppol BIS sense. The reserved credit is deducted at that point. |

`ACCEPTED` confirms delivery to the recipient's access point, not that the buyer
commercially accepted the invoice — Peppol does not track that. A negative MLS
message moves the invoice from `DELIVERED` to `REJECTED` and the credit reservation
is released. If no MLS message arrives within 25 minutes of sending, the invoice
moves to `UNCONFIRMED` and the credit is deducted (see below).

Tax reporting runs in parallel and does not affect the state of an outgoing
Peppol invoice — if the tax authority rejects the report, the invoice stays
`ACCEPTED` and the report is resubmitted.

### Non-Peppol domestic flow

<div class="lifecycle">
  <span class="lc">PENDING</span><span class="lc-arr">→</span>
  <span class="lc">VALIDATING</span><span class="lc-arr">→</span>
  <span class="lc">READY</span><span class="lc-arr">→</span>
  <span class="lc lc-final">DELIVERED_NON_PEPPOL</span>
</div>

For the receiver `0245:9970300001` (the domestic substitute outside the
Peppol network), the document is never sent over AS4 at all — only the tax
report goes to the tax authority. Once it is accepted, the invoice moves
straight to `DELIVERED_NON_PEPPOL` and credit is deducted immediately,
without waiting for delivery over Peppol.

### Inbound invoice

<div class="lifecycle">
  <span class="lc">RECEIVED</span><span class="lc-arr">→</span>
  <span class="lc lc-final">ACKNOWLEDGED</span>
</div>

Receipt sets `RECEIVED`, and an inbound invoice stays in that state until it is
acknowledged — validation does not change it. If the sender opted in to positive
MLS messages, we send one as soon as the document is stored, regardless of how
validation turns out; an inbound document is not rejected even on fatal
findings. The validation result is informational and you can read it through
`GET /api/v1/invoices/{id}/validation` — see [Validation](/developers/en/validacia/).
`ACKNOWLEDGED` does not happen automatically — it is set only by an explicit
acknowledgement: a call to `POST /sapi/document/receive/{id}/acknowledge` from
your system, or the “Acknowledge” button in the portal. Both paths are
idempotent and record the time of the first acknowledgement.

### Failure states

<div class="lifecycle">
  <span class="lc lc-fail">VALIDATION_FAILED</span>
  <span class="lc lc-fail">UNDELIVERABLE</span>
  <span class="lc lc-fail">FAILED</span>
  <span class="lc lc-warn">UNCONFIRMED</span>
  <span class="lc lc-fail">REJECTED</span>
  <span class="lc">CANCELLED</span>
</div>

| State | What happened, and what to do |
|---|---|
| `VALIDATION_FAILED` | A state the current flow does not set on an invoice; it remains among the possible values. A received document that fails validation is not rejected — it stays in `RECEIVED`, the sender gets a positive MLS message (if they opted in) and you find the findings in the validation result; no tax report is generated for it. Your own outbound invoice failing validation ends up as `REJECTED` below instead. |
| `UNDELIVERABLE` | The recipient could not be found in the routing registry (SMP). We retried three times (5 s, 30 s, 15 min) and then gave up; the reserved credit was returned. Check the buyer's Peppol ID — a typo, or a company that has not joined the Peppol network yet, is the usual cause. |
| `FAILED` | We found the buyer, but the transfer itself failed — their access point was unreachable or refused the connection. Same three attempts, same credit refund. Unlike `UNDELIVERABLE` this is not something on your side: resend the invoice later with a new idempotency key, and contact support if it keeps happening. |
| `UNCONFIRMED` | The recipient's access point received the message (AS4 receipt), but no MLS message arrived within 25 minutes of sending. This is not a send failure — the invoice was most likely delivered, we just cannot confirm it. The credit is deducted. The state is not final: if the MLS message arrives later, the invoice still moves to `ACCEPTED` or `REJECTED`, but the credit no longer changes. If the other party says they do not have the invoice, contact support. |
| `REJECTED` | Your outbound invoice failed validation outright and never entered the network, or the recipient's access point rejected it with a negative MLS message after receiving it (`DELIVERED`). For a recipient outside the Peppol network it also happens when the tax authority rejects the tax report. If the invoice was taken over Peppol and only the tax report is rejected, the status stays `ACCEPTED` and the report is resubmitted. Reserved credit is released. For a validation failure, fix the XML and resend with a new idempotency key; for a commercial rejection, nothing technically failed — resolve it with the other party. |
| `CANCELLED` | You cancelled it yourself. The API accepts a cancellation in `PENDING`, `VALIDATING` or `READY`; from `SENDING` on it answers `409` and the invoice carries on. A cancelled invoice is no longer sent over AS4. When cancelled in `READY`, however, the tax report may already have been generated and reported to the tax authority — cancelling does not withdraw it. For a recipient outside the Peppol network, acceptance of that report can still overwrite `CANCELLED` with `DELIVERED_NON_PEPPOL`. The portal therefore offers cancellation only in `PENDING` and `VALIDATING`. |