Outbound documents

This page describes the statuses of an outbound document — the one you send. It passes through seven statuses. The table and the diagram below are the same data shown twice — both are read from statuses.en.json, so they cannot drift apart.

Inbound documents have THEIR OWN dictionary

A document somebody else sent to you carries 1xx codes, in a separate table and with its own diagram: Inbound documents.

The first digit is the direction, the last two are the step — 210 Received against 110 Received. The two ranges deliberately do not overlap, neither with each other nor with the tax authority codes, so that one number can never mean two things. That is why you must not write one mapping for both lists.

The Final status? column says whether the document stops there for good. “Yes” means there is nowhere further to go — the document no longer changes and there is nothing to wait for. “No” means it can still move, by itself or after something you do, even when it has been sitting there for days.

Code	Name	What it means	Final status?
210	Received	The document reached us and was recorded. The answer to POST does not wait for processing — it returns straight away to say the document was taken over, and processing starts afterwards.	no
220	In processing	The document is with us and processing is under way — validation, signing, preparation for delivery.	no
225	Validated, not submitted	The UJP message has been composed and passed everything we are able to check, but the document was NOT submitted to the tax authority and will not be. This is the end of the trial run on the sandbox server: processing is finished, not under way, so no further change will follow. The composed message is available from GET outbound/{docUid}/file?format=ujp-json. This is not a failure and carries no failureCode — a document that fails validation gets 250 with EARH-4001.	no
230	Sent	The document has been submitted and is with the recipient or with UJP. From here the outcome is decided by the other side, so cancelling through the API is no longer possible — such a call returns EARH-3003.	no
240	Delivered	The document was delivered and accepted by the recipient. Cancelling through the API is no longer possible — the document is with the other side and such a call returns EARH-3003.	no
250	Failed	Processing or delivery ended unsuccessfully and stops here — it will not continue on its own. The exact reason is in failureCode, a code from the EARH-4xxx group. This is not a final status: cancelling is allowed from here as well, because the document never left for the recipient.	no
260	Cancelled	The document was cancelled at your request. Cancelling does not delete — the document still comes back by its docUid, and the transition stays in the history with its own timestamp. A second cancel returns EARH-3004.	yes
270	Archived	The document has been placed in the archive and its life cycle is finished. Cancelling is no longer possible — such a call returns EARH-3003.	yes

Transitions

The status at UJP is a separate piece of data

UJP’s answer is a separate piece of data with its own code. That code never appears as a value in the table above — only our own seven document statuses live there, and none of them comes from UJP.

The two are easiest to mix up at EARH-4002: that code means UJP rejected the document, while the real reason — UJP’s own code and description — sits in the ujp block of the response. On our side the document is then in status 250 Failed, whatever that block says.

So the status says how far the document has got with us, and the ujp block says what UJP said. Neither is computed from the other and neither is shown in place of the other.