Why is an eFact invoice rejected?

Most often: invalid insurability (MDA), the wrong mutuality on the record, an allowance declared beyond the end of the INAMI intervention, an unclosed absence, a missing Katz category, an incorrect NISS or a duplicate sending. The rejection code and reason returned by the insurance organisation indicate the cause.

What should you do when an eFact batch is rejected?

You do not resend a batch as-is: you fix the cause at the source (MDA, mutuality, Katz, dates…), regenerate, then resend. The Resends counter tracks retransmissions to avoid duplicates.

What is the difference between a global rejection and a partial rejection?

A partial rejection refuses only some lines (the rest is paid): you fix and resend only those lines. A global rejection refuses the whole batch: you fix the cause and resend a new batch.

How do I correct an over-invoicing (departure, death, over-declared allowance)?

Resthome detects it through the self-check and prepares a credit note on the resident side and, if the mutuality share is affected, a corrective batch to the insurance organisation. The credit lines are included in the next sending.

eFact rejections — causes and solutions¶

When you send the eFact, the insurance organisation (OA) checks each line and returns a result to you. This page explains how to read a response, why a batch or a line is rejected, and how to fix it, then resend.

Two lines of defence

Most rejection causes are intercepted by Resthome before sending (period self-check, checks at generation). They then appear as an anomaly message to handle, not as a rejection. The cases that slip through anyway then come back as an OA rejection. This page covers both.

The response cycle, in plain terms¶

After a batch is sent, the OA’s responses advance the batch status and fill in the amounts (invoiced / accepted / refused):

Acknowledgement of receipt — the OA confirms having received the file and passed the first check. Nothing to do.
OA settlement — the OA returns the result line by line: what is accepted and what is refused. Resthome reconciles this settlement and updates the batch amounts.
Acceptance and/or rejection — three possible outcomes:
- everything is accepted → the batch is settled, then can be closed;
- partial rejection — some lines are refused, the rest is paid: you fix and resend only the refused lines;
- global rejection — the whole batch is refused, nothing is paid: you fix the cause and resend a new batch.

When is a batch rejected globally?

The insurance organisation rejects the whole batch (920099) in case of a blocking error or when the error rate exceeds about 5% of the lines. Below that, the faulty lines are subject to a partial rejection and the rest is paid — which is why it pays to handle the self-check and the MDA before sending.

Reading a list where batches have been resent¶

A rejected batch is never modified in place: fixing it produces a resend, a new batch that takes over. Over a month, one invoice can therefore be carried by a chain of batches. The list is built to show you the thread, not the paperwork.

The status you see on a row is the status of the whole thread — the last resend in the chain. A batch that was rejected, resent and then paid reads Settled, because that is where the invoice actually stands.
The Current batch column names the live batch of the thread.
Opening a rejected head lands you on a banner — Resend already created — with an Open the live resend button. Its own status below is historical: the corrections belong on the live resend, not here.

“My batches have disappeared”

The list opens on the Active threads filter, which folds away the threads already superseded — globally rejected then re-submitted, or waived — when a fresh submission covers the same insurer for the same month. One live row per insurer, instead of a pile of dead ends.

Nothing is deleted. Switch to the Superseded / waived filter to see them, or open the live batch and use its Resends / lifecycle (☰) button, which lists every batch that has billed this insurer for this month.

On each refused line, a code and a rejection reason in plain language point to the cause.

eFact batch lines list showing the refused lines with their rejection code and reason

Frequent rejection causes → action¶

Cause	What you see	Action in Resthome
Invalid or missing insurability (MDA)	The MDA counter is not green; batch held back at sending; or an OA rejection for insurability	Run Check MDA, get the Success status for each resident, then regenerate the eFact. The MDA must be validated before generating.
Wrong or missing mutuality	The allowance goes to the wrong OA (rejection) or does not appear in the batch	Enter/correct the mutuality on the resident’s record, then regenerate. Check that each resident invoiced under third-party payment does have a mutuality.
Allowance declared beyond the end of the intervention	Self-check: “Over-declared OA allowance”; the OA refuses the extra days	Issue a credit note / remainder for the over-declared days (see below).
Room freed / death — accommodation still invoiced	Self-check: over-invoicing; refusal of the undue days	Close the accommodation on the correct date + credit note.
Unclosed absence	The Absences counter is active; allowance days are distorted	Close the period’s absences, then re-check.
Missing Katz category or expired evaluation	The “Katz to do” counter; blocked at generation	Complete or renew the Katz evaluation, then regenerate.
Missing or incorrect NISS	Mandatory identification data → technical rejection	Correct the NISS on the resident’s record, then regenerate.
Duplicate sending	The OA reports an already received sending	Do not resend an already accepted batch. For a legitimate resend, rely on the Resends counter (anti-duplicate).
Amount / rate mismatch	The OA returns an unexpected amount/rate	Check the applied rate and the line amount, correct the configuration, regenerate, resend.
Technical / format rejection	Global rejection: the file did not pass the format check	Rare case to escalate: use Contact OA or Helpdesk, fix, then resend a new batch.

Resend, or waive the rejection¶

A rejected batch leaves you with two paths, and Resthome tracks both.

Retransmit¶

Retransmit builds a new batch from the rejected one. Each line is re-routed to the health insurance fund the resident actually belongs to today — which is often what the rejection was about.

If the lines now belong to several funds, Resthome creates one batch per fund.
A batch can only be retransmitted once: if a resend already exists, Resthome points you to it rather than creating a duplicate.

Retransmit re-sends unchanged content

If the billing was corrected since the batch was sent — a stay closed, a death capped, lines regenerated — retransmitting would re-send the amounts from before the correction. Resthome detects it and sends you to the regeneration flow instead, which rebuilds from the current billing.

Waive¶

Sometimes the rejection is right and there is nothing to correct. Waive records that decision: the batch will not be resent, the fund’s rejection stands, and the batch leaves the “To resend” worklist.

It is reversible: a waived batch can be put back on the worklist at any time. Both the waiver and its cancellation are written to the batch’s log, so the decision stays traceable.

Waiving is a management decision

It is not a way of tidying up the list. Waiving means accepting the loss of the amount concerned — which is sometimes the right call when the correction would cost more than it recovers.

Fix, then resend¶

The principle: you do not resend a rejected batch as-is — you fix the cause at the source, then resend.

Fix → resend loop. After handling the cause (MDA, mutuality, Katz, absence, dates…), regenerate the affected part and resend. The Resends counter keeps track of each retransmission to avoid sending the same batch twice.
Reintegration. The Reintegration button lets you reintegrate lines (for example rejected lines, once corrected) into a new sending, rather than redoing everything.
Credit note / corrective batch. Whenever you have invoiced more than due — a departure or death during an already invoiced month, an over-declared allowance — Resthome prepares a credit note (on the resident side) and, if the mutuality share is affected, a corrective batch to the OA. The credit lines are included in the next eFact sending.

The responses you may come across¶

Depending on the message returned by the OA, you may see, in the statuses or the batch log:

Response	Code	What it means
Acknowledgement of receipt	931000	The OA has received the file and it passed the first check. Normal step.
Notification with warnings	920098	The batch is accepted, but with warnings (minor errors) to read.
Settlement	920900	The line-by-line result: accepted and refused amounts. This is where the partial rejections to fix appear.
Global rejection	920099	The whole batch is refused (too many errors). Fix the cause and resend a new batch.
Technical rejection	920999	The file did not pass the format check; retransmission required after correction.

Key points¶

Prevent rather than cure: handle the self-check messages and validate the MDA before invoicing — this way, most rejections are avoided.
A partial rejection is fixed line by line; a global rejection is resent as a new batch.
An over-invoicing (departure, death, over-declared allowance) is corrected with a credit note / corrective batch, not with a simple resend.