Inbound documents

An inbound document — one somebody else sent to you — has its own life cycle and its own status dictionary. It is not a continuation of the dictionary of outbound documents: the two are separate, and no code exists in both.

The first digit is the direction, the last two are the step

Inbound documents carry 1xx, outbound ones 2xx. The last two digits are the same step of the life cycle in both directions:

Step	Inbound	Outbound
Received on our side	110	210
In processing	120	220
Sent to the other side	—	230
Accepted / Delivered	140	240
Rejected / Failed	150	250
Cancelled	—	260
Archived	170	270
Final document from the tax authority	180	—

The dash is data, not a gap. You do not send and do not cancel an inbound document — the issuer does, and on your side that shows up as a state of the tax authority.

The ranges are kept apart so that one and the same number can never mean two things — neither between the two lists, nor against the tax authority codes, which are two-digit while ours are three.

So: do not write one mapping for both lists. Which list you are reading is known from the address you are on — inbound or outbound.

Statuses of an inbound document

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?
110	Received	The document arrived on our side and was recorded. It stays here until somebody at the recipient starts working with it — and this is where every document you have not fetched yet sits.	no
120	In processing	The document is being processed by the recipient: read, checked and prepared for a decision. No decision has been made yet, so the deadline in decisionDeadline is still running.	no
140	Approved	The document was approved. The decision is recorded on our side and is being reported to the tax authority — recorded does not mean confirmed, so this is not a final status: the final document from the tax authority arrives after the confirmation.	no
150	Rejected	The document was rejected. The answer then also carries the reason for the rejection in text, so that nobody has to contact support to find out what happened.	no
170	Archived reserved — not returned yet	RESERVED — the number is taken, the state does not exist yet. The step “archived” is the same in both directions (270 for outbound); for inbound documents it arrives together with the final document from the tax authority. It is published so that you can see that 140 Approved is NOT a final status: a client that reads it as final stops asking about a document whose life cycle is still running.	no
180	Final document received from the tax authority reserved — not returned yet	RESERVED — the number is taken, the state does not exist yet. The API will not return it until fetching the final signed document from the tax authority is delivered. This is the last step in the life cycle of an inbound document.	yes

Transitions

Why 140 Approved is not a final status

The decision is not the end of the life cycle. After it the document is archived on our side, and the tax authority returns a final signed document. That is why the table also carries the codes 170 and 180, marked as reserved.

What reserved means	the number is taken, the state does not exist yet
What the API does today	it does not return them — no answer carries 170 or 180
Why they are published anyway	without them 140 looks like a final status, so a client that read it that way stops asking about a document whose life cycle is still running

When the state does start coming back, it will be announced through the Changelog — like every other extension.

A rejected document carries the reason

When the document is in 150 Rejected, the answer also carries the reason for the rejection in text. Nobody has to contact support to find out what happened.

The reason is picked from the reject-reasons code list, which is read from GET /codelists/reject-reasons. That is the same code list the code comes from when you reject a document through POST /inbound/{docUid}/decision.

The deadline for a decision — decisionDeadline

Every inbound document carries a decisionDeadline field: the calendar day by which the document has to be approved or rejected. When no deadline is set for the document, the field is null — not an invented day.

The field is in both the list and the detail, so that documents still waiting for a decision can be ranked by how little time is left, without fetching each one in full.

The deadline is a DATE, not a moment and not a countdown

decisionDeadline is a date: 2026-09-15. It carries no time and no zone, and therefore it never depends on the clock of whoever reads it.

The answer deliberately has no field with the days remaining. Such a number goes stale inside the body: a caller that cached the answer across midnight would read a number that no longer holds, with nothing to report it. The arithmetic is yours, with your own clock — and the date it works from does not change.

Once the deadline has passed, the tax authority accepts the document on its own. So a caller who is still deciding has to read this field to know how long it has left. The deadline survives the decision: a document that has been decided keeps its decisionDeadline — that is the difference from the rejection reason, which only appears once the document is rejected.

What you have fetched, and what has changed

Two things that look alike but ask different questions:

Question	How to ask it
“What have I not fetched yet?”	onlyNotImported=true
“What has changed since my last pull?”	by=updated with dateFrom

A document you already fetched and that was then approved comes back only with by=updated. The two are not interchangeable; for the details of incremental pulling see Limits and rules.

Downloading the content

GET inbound/{docUid}/file returns the document’s content. It takes a format parameter, and that parameter accepts exactly three values:

format	What it returns	When it is available
original	the file exactly as it arrived, whatever its kind	always, if the document carries content at all
ubl	the content as UBL, that is, as XML	only if the document arrived as XML
pdf	the accompanying PDF	only if a PDF arrived with the document

⛔ No representation is produced on demand. If the document did not arrive as XML, ubl returns 404 — we will not convert it in order to satisfy the request. The same holds for pdf.

ubl returns 404 for a document that arrived as UJP JSON

A large share of inbound invoices arrive as machine-readable UJP JSON, not as XML. For those, format=ubl returns 404 — and that is behaviour, not an omission. You take the content with format=original.

The three outcomes and how to tell them apart

Response	Code	What it means
200	—	the content is returned
404	EARH-3001	no such document, or the document is not yours
404	EARH-3002	the document exists but did not arrive in the requested representation
409	EARH-9003	the representation existed and its content is lost on our side

⚠️ EARH-3002 and EARH-9003 look alike and mean opposite things. The first is an orderly state your software simply skips: that representation never existed. The second means it did and we lost it — there is nothing to fix in the call, and it is worth telling us.

📌 In both cases everything else about the document still reads normally: the status, the amounts, the history.

---

How to get inbound documents for a trial run

On the sandbox server your organisation has no inbound documents at all: they are delivered by the tax authority, and there we do not talk to them. That is why two endpoints exist to fill it, and they answer different questions:

When you need it	Take
Every state described on this page — including the ones you cannot create yourself, such as an expired deadline or a decision already made	A series by scenario
One specific document with your content — a file from a real customer that breaks your parsing, say	One invoice with your own content

⛔ Both exist only on the sandbox server.