The VECOZO connection
Billing a health insurer runs through VECOZO. This guide describes the route there in the order a practice hits it: how you get access, which certificate you actually need for it, and — most importantly — how you see what the insurer did with your declaration.
It is intended for the practice owner and the finance administration. For the billing work itself (preparing appointments, creating batches, downloading) see Declaring.
In short
| # | Step | Where |
|---|---|---|
| 1 | Authorise Scrivio to declare on behalf of the practice's AGB code | At VECOZO |
| 2 | Make sure whoever works in the VECOZO portal has a personal certificate — and install it within 20 days | At VECOZO |
| 3 | Declare: prepare appointments, create a batch, finalise it, download it | Declaring |
| 4 | Submit the declaration file and mark the batch as Submitted | In the VECOZO portal, then in Scrivio |
| 5 | Download the return information | In the VECOZO portal |
| 6 | Import the return file into Scrivio | Declaring → Import return information |
| 7 | Re-declare rejected lines | Declaring → Batches |
Access comes from an authorisation, not from a certificate
VECOZO lets a software supplier act on behalf of a practice on the basis of permission, not on the basis of a certificate belonging to that practice. Scrivio uses its own system certificate and a connection registered with VECOZO for that. What has to be added per practice is an authorisation (machtiging, toestemmingsverklaring) for the practice's AGB code, granted in VECOZO's own portal. Every message Scrivio sends on your behalf names that AGB code, and VECOZO checks on its side that the authorisation is there.
What you arrange yourself:
- the practice's AGB code, recorded under Practice details — without an AGB code VECOZO has nothing to attach an authorisation to;
- the authorisation to Scrivio, in the VECOZO portal;
- a personal VECOZO certificate for everyone who works in that portal (see below).
No system certificate for the practice has to be requested, collected or uploaded. A system certificate belonging to the practice changes nothing about what Scrivio can do at VECOZO.
You arrange the authorisation together with Scrivio during onboarding. It is an arrangement on the VECOZO side and the procedure differs per situation, so we walk you through it. This page therefore describes what is needed, not the click path in the VECOZO portal.
The personal certificate, and the 20 days
A personal certificate belongs to a person and is what you sign in to VECOZO with. You need one, because submitting the declaration file and retrieving the return information are things you do yourself in the VECOZO portal. A system certificate belongs to a practice and is meant for a system declaring on that practice's behalf — exactly what Scrivio does with its own certificate, and so nothing your practice has to request.
Confusing the two is what costs the most time. The one you need is the personal one.
Install a new or renewed certificate within 20 days. VECOZO sends a user number and a PIN with which you install the certificate, and applies a 20-day term to it. If that does not happen in time, the certificate and the VECOZO account it belongs to are deleted for security reasons, and the contact person has to request a new account. You usually notice this at the moment you want to declare, and by then you have lost the waiting time all over again.
A real example: a practice requested a certificate in early July, put off installing it, and the first test declaration in mid-August could not go ahead. Nothing had gone wrong with the request — twenty days had simply passed.
So plan the installation right when you request it. This is not a setting in Scrivio; the current conditions are stated by VECOZO itself.
Where the return information lands
This is the part that costs the most money if you do not know it: a rejection does not announce itself.
The insurer's answer — the return information — arrives at VECOZO. Scrivio does not fetch it from there on its own: you download it in the VECOZO portal and import it into Scrivio (see below). Until that has happened a batch stays on Submitted, even when the insurer rejected it long ago. A batch sitting there quietly is therefore not confirmation that you have been paid.
In Scrivio a batch goes through four steps — you see them in the batch detail panel under Verloop van deze batch:
| Step | Meaning |
|---|---|
| Concept | Still editable. A download is a draft of the declaration message. |
| Ready | Fixed. A download gives you the message you submit at VECOZO. |
| Submitted | Submitted to the insurer; awaiting the return message. You set this step yourself with Mark as submitted, as soon as you have submitted the file. |
| Return received | The insurer has answered: approved, rejected or partially approved. |
These are the four steps of the route; the full list of batch statuses is on Declaring → Filter and preview batches.
Retrieve the return information after every submitted batch. Without that step nobody knows whether a declaration was approved, rejected or partially granted. One practice that did not do this only discovered months later that its largest insurer was rejecting structurally — while the salaries still had to be paid.
Make it a fixed step in your monthly rhythm: submit, and a few days later download the return information and import it.
Importing the return information
You do not have to work out which message belongs to which batch. Download the return information in the VECOZO portal and upload the file in one go under Declaring → Import return information: Scrivio reads every message in the archive and attaches it to the batch whose invoice reference it names. One upload covers every insurer you submitted to.
Re-uploading is fine. Overlapping downloads are safe: per batch the newest answer applies, and an older message is kept but not applied. If you are not sure what has already been read in, simply import the download again.
What the insurer answered
Open a batch under Declaring → Batches to read the answer. That answer comes in two shapes, and both are normal:
- Per declaration line. Next to the declared amount you see the granted amount and the return code with its Dutch meaning beside it, so you can see at once whether this is one problem repeated twelve times or twelve different ones. As long as no return message has been imported, those two columns are not shown.
- For the declaration as a whole. An insurer accepting or refusing a declaration outright often names no line at all. You then see, above the lines, what it read as declared, what it granted, and the return codes it attached to the message itself. Such a message is not empty and not broken: that is the whole answer.
What the answer does to the batch's status:
| The insurer | Batch status |
|---|---|
| grants everything | Approved |
| grants part of it, or rejects part of the lines | Partially approved |
| grants nothing — including when it rejects the whole declaration outright | Rejected |
The Beantwoord button above the batch list shows those three statuses at once: which batches has the insurer answered? Filtering on each status separately is possible too.
This page deliberately names no return codes, so that no list arises here that does not move with the national one; the meaning is shown in Scrivio next to the line itself.
Technical rejection or content rejection
A declaration can fail at two very different moments, and the difference decides what you do about it.
| Technical rejection | Content rejection | |
|---|---|---|
| When | At message level, before any assessment of the content. | Per declaration line, after assessment by the insurer. |
| What happened | The file was not taken into processing. Nothing was declared and nothing was booked. | The declaration was processed. Lines were rejected or partially granted. |
| Where you see it | On the batch, once you have imported the return information: the return code is then on the declaration as a whole. | On the batch, per declaration line. |
| What you do | Fix what is wrong and submit again. | Re-declare the batch (see below). |
Neither of the two needs a credit note. With a rejection nothing was granted, so there is nothing to reverse. Crediting only comes into play when a declaration was approved and turns out to be wrong afterwards. For private and paper invoices that runs via Invoices → Create a credit note; for an approved VECOZO batch Scrivio deliberately refuses Re-declare — the same care would be billed twice — so contact Scrivio in that case.
If you are unsure what the insurer expects of you, follow what the return message itself says.
Re-declaring a rejected batch
If a batch was rejected, you handle it on the Batches tab in Declaring:
- Find the batch and first correct what the insurer rejected — the return code on the line says what it is about: the citizen service number, the referral or the performance code, for instance.
- Choose Re-declare on the batch.
- The billing lines go back to Ready and return to the open consultations. The batch itself stays exactly as it is, as the record of what you submitted. On a partially approved batch, only the rejected lines come along — see below.
- Put those lines into a new batch. It gets a new batch number and with it a new invoice reference — the reference an insurer asks for on a resubmission.
Re-declare is available for a batch that is Submitted, Rejected or Partially approved. The other statuses are deliberately excluded:
- Approved — that care has been granted; re-declaring would bill it a second time.
- Concept, Ready and Exported — Scrivio has not recorded a submission yet. If you did submit the batch, first set it to Submitted with Mark as submitted.
Partially approved: only the rejected lines
If the insurer granted part of the declaration, Re-declare releases only the lines that were rejected. Approved lines stay on the original batch and are never declared again — so you no longer have to keep track of the difference by hand. The message after the action says how many lines were released.
Two kinds of line are not released, and that is deliberate:
- A line for which the insurer granted a lower amount. That is an approval with a return code, not a rejection; that care has been paid for.
- A line the return message says nothing about. It has not been assessed yet, and an unanswered line is not a rejection.
If the return message holds no rejection at all, Scrivio reports that there is nothing to release instead of pretending the batch is on its way again. In that case, first import the return message (see Where the return information lands) so the insurer's answer is recorded per line.