# Overview (/en-GB/aan-de-slag)

This page takes you through your first day in Tillor, from signing in to your first invoice. The order matters, because each part builds on the previous one. An occupation, for example, needs a customer and a terrain, so you create those first. If you would rather follow a real-life example, see [In practice](/praktijk). If you come across a word you do not know, look it up in [Terms](/begrippen).

## How does it all fit together? [#hoe-hangt-dit-samen]

These are the building blocks and what they need:

```mermaid
flowchart LR
  I[Instellingen] --> T[Terreinen]
  T --> B[Bezetting]
  T --> R[Reservering]
  K[Klanten] --> B
  K --> R
  P[Producten] --> F[Factuur]
  K --> F
  B --> F
  R --> F
  F --> Bet[Betaling]
```

An invoice always belongs to a customer. A customer on a terrain for a longer period is called an occupation, and a stay with a check-in and check-out date is a reservation. Products are not mandatory, but they make sure the price, VAT and actions on the invoice line are correct.

<Callout type="info" title="Good to know">
- If you have more than one organisation, you choose one after signing in. If one is missing, ask your administrator to invite you.
- Which menu items you see depends on your permissions. If you cannot see something, ask your administrator for the permission.
- Without a terrain you cannot create an occupation. Without a customer you cannot create a reservation, an occupation or an invoice.
- Cash, bank transfer and other manual payments work without a connection. For online or card payments you connect Mollie.
- The quickest way to find something is to search with **Ctrl+K** or **⌘K**.
</Callout>

Before you start:

- You have a Microsoft, Google or Apple account and your administrator has invited you to your organisation. Without an invitation you will not see an organisation.
- You have the permissions for what you want to do. If you lack them, the menu item is missing or the button is greyed out.

## Setting up your park [#je-park-inrichten]

<Steps>
<Step>
### Sign in and choose your organisation [#log-in-en-kies-je-organisatie]
Sign in with your Microsoft, Google or Apple account. If you have access to more than one organisation, choose one. If you do not have access yet, ask your administrator to invite you. See [Signing in](/inloggen).
</Step>
<Step>
### Review the organisation settings [#loop-de-organisatie-instellingen-na]
Open <UIPath>Support > Settings</UIPath>. Under **General**, check the time zone and the default country, and under **Opening hours** enter your opening times. Under **Invoicing** you will find, among other things, the default payment term and the VAT rates. You invite colleagues under **Users**. See [Organisation](/gebruikers/organisaties).
</Step>
<Step>
### Create your terrains [#maak-je-terreinen-aan]
Go to <UIPath>Park > Terrains</UIPath> and add your spots, such as pitches, chalets and permanent places. Without a terrain you cannot create an occupation, and you link meters to a terrain. See [Terrains](/terreinen).
</Step>
<Step>
### Create your products [#maak-je-producten-aan]
Go to <UIPath>Administration > Products</UIPath> and create the rates and services that appear on invoices, such as overnight stays. An invoice line can also be added without a product, but with a product the price, VAT and any actions are correct straight away. See [Products](/producten).
</Step>
<Step>
### Add your customers [#voeg-je-klanten-toe]
Go to <UIPath>Customers > Overview</UIPath> and create a customer. Reservations, occupations and invoices always belong to a customer. See [Customer management](/klantenbeheer).
</Step>
<Step>
### Create a reservation or occupation [#maak-een-reservering-of-bezetting-aan]
A reservation is for a stay with a check-in and check-out date, and you can also create one without a fixed terrain. An occupation links a customer to a terrain for a longer period, for example a seasonal pitch. See [Reservations](/reserveringen) and [Occupations](/bezettingen).
</Step>
<Step>
### Create your first invoice [#maak-je-eerste-factuur]
Open the customer's profile and create a new invoice there. Add lines, book the invoice and send it. See [Invoices](/facturen).
</Step>
<Step>
### Connect payments [#koppel-betalingen]
If you want customers to pay online or by card, connect Mollie via <UIPath>Support > Settings</UIPath> under **Integrations**. Cash, bank transfer and other manual payments work without a connection. See [Payment processing](/betalingsverwerking) and [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie).
</Step>
</Steps>

If you use meters, barriers or NFC tags, you set those up afterwards. Start with [Park](/park) and [Access control](/toegangscontrole).

## What happens next? [#wat-gebeurt-er-daarna]

- Your customers, terrains and products are ready, so you can create reservations, occupations and invoices every day.
- Your first invoice is saved as a draft on the customer. Only after **Book** does it get a final number, and after that you can send it and have it paid.
- If you have connected Mollie, customers can pay online or by card and the payment comes back to the invoice automatically.

## Finding your way around [#je-weg-vinden]

The main menu is on the left. At the top you switch organisation if you have more than one. Which items you see depends on your permissions.

<DocScreenshot src="/screenshots/inleiding/dashboard-welcome.png" alt="Dashboard - start screen after signing in" />

| Menu | What it is for |
|------|----------------|
| **Dashboard** | Start screen with today's arrivals and departures |
| **Reservations** | Stays and the reservation calendar |
| **Tasks** | Dividing up and following up work |
| **Access Control** | Access points and the access log |
| **Customers** | **Overview** and **Outstanding Consumption** |
| **Park** | **Map**, **Terrains**, **Meters**, **Meter Cabinets** and **Weather** |
| **Communication** | **Phone Calls**, **Notifications** and **Comments** |
| **Administration** | **Documents**, **Signature requests**, **Invoices**, **Payments**, **Bank transactions** (with the permission to view them), **Payment Reports**, **Print queue** and **Products** |

Under the heading **Admin** you will find **Automations** (with the permission to view them) and **Controllers**. At the bottom, under **Support**, you will find your notifications, **Inbox** and **Audit log** (with the corresponding permissions), **Settings** and **More resources** with the documentation. Which items you see depends on your permissions.

You search with **Search** in the header, or with **⌘K** (Mac) or **Ctrl+K** (Windows). This takes you straight to a customer, invoice, reservation or terrain. See [Search](/zoeken).

You find your own account, sessions and API keys via your name at the bottom of the menu.


## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot get into my organisation">
Your administrator has to invite you first. Sign in with the account they invited. See [Signing in](/inloggen).
</Accordion>
<Accordion title="I cannot see a menu item that is mentioned in this manual">
You only see the items you have permissions for. Ask your administrator for the permission, or for the role that includes it.
</Accordion>
<Accordion title="I cannot create an occupation">
No terrain is available, or the customer does not exist yet. Create a terrain and a customer first. A terrain with an ongoing occupation does not appear in the selection list.
</Accordion>
<Accordion title="I do not know where to find something">
Use **Search** in the header, or search this manual with the search bar at the top.
</Accordion>
</Accordions>

## Need help? [#hulp-nodig]

- If you are looking for something in this manual, use the search bar at the top or choose **More resources > Documentation** in Tillor.
- Is Tillor not working as expected? First check the [system status](https://status.tillor.eu) for outages and planned maintenance.
- Missing access to an organisation, or want to change company details on invoices? Email support@tillor.eu.
- Want to restore data from a backup? See [Data and backups](/gegevens-backups).

## Terms [#begrippen]

- **Organisation**: your Tillor account, usually your company. See [Terms](/begrippen#organisatie).
- **Park**: the physical place. See [Terms](/begrippen#park).
- **Customer**: a person or company in Tillor. See [Terms](/begrippen#klant).
- **Terrain**: a spot in your park. See [Terms](/begrippen#terrein).
- **Occupation** and **reservation**: a customer on a terrain for a longer period, or a stay with a check-in and check-out date. See [Terms](/begrippen#bezetting).
- **Book**: making an invoice final. See [Terms](/begrippen#boeken).

## See also [#zie-ook]

<Cards>
  <Card title="In practice" href="/praktijk" description="Worked examples of a working day" />
  <Card title="Terms" href="/begrippen" description="All terms at a glance" />
  <Card title="Signing in" href="/inloggen" description="Sign-in methods and your account" />
  <Card title="Search" href="/zoeken" description="Quickly find what you are looking for" />
  <Card title="Data and backups" href="/gegevens-backups" description="Retention periods and recovery" />
  <Card title="What's new" href="/wat-is-nieuw" description="Recent changes per month" />
</Cards>


# Terms (/en-GB/begrippen)

Tillor uses a few words more often than you may be used to, and some of them look alike. This page explains what each term means and where to read more about it. The list is in alphabetical order. If you are looking for something about controllers themselves, such as ACL or firmware, see the [controllers glossary](/controllers/lexicon).

<Callout type="info" title="Two words that are often mixed up">
An **occupation** is a customer who stays on a terrain for a longer period, such as a seasonal customer. A **reservation** is a booking for a single stay. In Tillor, **book** always means making an invoice final, never reserving a stay.
</Callout>

### Reminder [#aanmaning]

A reminder to a customer that a booked invoice has not been paid yet. You send it per invoice, with the same link to pay online. See [Sending a reminder](/facturen/versturen#een-aanmaning-versturen).

### Automation [#automatisering]

A rule that Tillor carries out by itself: when this happens, do that. For example, create a follow-up task when an occupation ends. The steps of one automation together form a flow, the drawing on the canvas. See [Automations](/automatiseringen).

### Payment [#betaling]

An amount that a customer pays or that is still on its way, with a method, a status and usually an invoice. You find them under <UIPath>Administration > Payments</UIPath>. See [Finding payments](/betalingsverwerking/betalingen-bekijken).

### Payment group [#betalingsgroep]

A bundle of payments under one name, which you later link to a booked invoice in one go. For example, all card payments of one day. See [Payment groups](/betalingsverwerking/groepen).

### Payment report [#betalingsrapport]

The overview of all payments on one calendar day, intended for your accounting. Today's report is a draft and becomes final when the day is over. See [Payment reports](/boekhouden/betalingsrapporten).

### Evidence page [#bewijspagina]

The pages at the end of a signed PDF, with the title of the document, who signed when and two digital fingerprints. They are called **Signing evidence** and later show that the document has not been changed. See [Evidence and validity](/handtekeningen/bewijs-en-geldigheid).

### Occupation [#bezetting]

A customer who is on a terrain for a longer period. As long as the occupation runs, Tillor charges the consumption of the meters on that terrain to that customer. A terrain has at most one customer at a time. See [Occupations](/bezettingen).

### Book [#boeken]

Making a draft invoice final. The invoice gets an invoice number and you can no longer change it freely afterwards. In Tillor the word has nothing to do with reserving. See [Booking an invoice](/facturen/boeken).

### Draft [#concept]

An invoice that has not been booked yet. You can still change the lines and nothing has gone to the customer or to the accounting yet. See [Invoice statuses](/facturen/statussen).

### Connector [#connector]

A small box in your park's network that connects Tillor to devices on site, such as printers and access controllers. Tillor supplies it preconfigured and updates it itself. See [Connector](/connector).

### Controller [#controller]

A box with a touchscreen in your park, at a shower or a door. It reads an NFC tag or a QR code, and Tillor decides whether the guest may go through. You manage controllers under **Controllers**. See [Controllers](/controllers).

### Credit note [#creditnota]

An invoice with negative amounts that cancels an earlier invoice. The app calls this a **Credit Invoice**. You create it with **Reverse invoice**. See [Reversing an invoice](/facturen/corrigeren#een-factuur-omkeren).

### Custom field [#eigen-veld]

A field that your organisation adds itself to a customer, terrain, occupation, meter or task, on top of the fields Tillor comes with. You manage them under <UIPath>Settings > Custom fields</UIPath>. See [Custom fields](/eigen-velden).

### Invoice [#factuur]

What you charge a customer, with lines per product. A new invoice is always a draft. You create it on the customer profile and manage all invoices under <UIPath>Administration > Invoices</UIPath>. See [Invoices](/facturen).

### Event [#gebeurtenis]

A line in the timeline of a customer, invoice or other record that shows what happened, by whom and what changed. See [Activity log](/activiteitenlog).

### User [#gebruiker]

An account with access to Tillor. In running text we call another user a colleague. You manage users and their permissions under <UIPath>Settings > Users</UIPath>. See [Organisation](/gebruikers/organisaties).

### Group [#groep]

A fixed set of colleagues, for example **Front desk**. You assign tasks to a group, share views with a group and can give or take away permissions for a group. See [Groups](/gebruikers/groepen). A payment group is something different.

### Ledger [#grootboek]

The account number in your accounting to which a product is booked. You enter it on the product, and it is sent along when you pass data on to your accounting. See [The ledger number](/producten/product-aanmaken#grootboeknummer).

### Direct debit [#incasso]

Tillor collects the amount of an invoice from the customer's bank account by itself. This only works with an active mandate. See [Collecting an invoice by direct debit](/betalingsverwerking/incasso).

### Choice list [#keuzelijst]

A fixed list of options that a custom field of the type **Choice** or **Multiple choice** draws on. You create the list once and use it in several fields. See [Choice lists](/eigen-velden/keuzelijsten).

### Kiosk [#kiosk]

An Android tablet that shows the Tillor app and stays there, so guests cannot reach the device's settings. See [Setting up a kiosk](/mobiele-app/kiosk-inrichten).

### Customer [#klant]

The record in Tillor of a person or company: details, invoices, occupations, access methods and more. We only use the word guest in running text for someone who stays at your park. See [Customer management](/klantenbeheer).

### Mandate [#mandaat]

A customer's permission to collect invoices from their bank account (a SEPA mandate). The customer signs it in Tillor itself. See [Having a SEPA mandate signed](/betalingsverwerking/mandaat).

### Meter [#meter]

A device for water, electricity or gas. A meter belongs to a terrain, not to a customer. The consumption goes to the customer who has an occupation on the terrain at that moment. See [Meter management](/meterbeheer).

### Meter cabinet [#meterkast]

A cabinet that holds meters. Under <UIPath>Park > Meter Cabinets</UIPath> you manage the meter cabinets and the meters assigned to them. See [Park](/park#meterkasten).

### NFC tag [#nfc-tag]

A card, wristband or key fob that a guest holds against a controller, for example for the shower or an access point. A tag can have a balance. See [NFC](/nfc).

### Notification [#notificatie]

A message that Tillor sends to a customer or colleague, by email, SMS, post, WhatsApp or push. Under <UIPath>Communication > Notifications</UIPath> you can see whether it arrived. See [Notifications](/notificaties).

### Signature request [#ondertekenverzoek]

A request to have a PDF, such as a rental contract, signed online by one or more people in turn. You manage them under <UIPath>Administration > Signature requests</UIPath>. See [Signatures](/handtekeningen).

### Outstanding consumption [#openstaand-verbruik]

Consumption of meters that is not on an invoice yet. You see it per customer under <UIPath>Customers > Outstanding Consumption</UIPath> and invoice it with **Invoice consumption**. See [Meter management](/meterbeheer/verbruik-factureren).

### Comment [#opmerking]

An internal note on a customer, invoice, reservation or other record. Comments are never visible to the customer. See [Comments](/notities).

### Organisation [#organisatie]

Your Tillor account, so your company with its users, settings and data. The park is the physical place. See [Organisation](/gebruikers/organisaties).

### Park [#park]

The physical place: your campsite or holiday park. Under **Park** you find the map, the terrains, the meters and the meter cabinets. See [Park](/park).

### Peppol [#peppol]

A European network that lets you send invoices electronically straight to the recipient's accounting system, without a PDF. For Belgian invoices to companies with a VAT number it is mandatory. See [Peppol](/boekhouden/peppol).

### Product [#product]

A rate or service that you put on an invoice line, such as a night, a pitch fee or a kWh of electricity. A product can have actions that Tillor carries out when booking or paying. See [Products](/producten).

### Product action [#productactie]

Something Tillor does automatically when an invoice line with this product is booked or paid, such as extending an occupation or topping up an NFC tag. See [Product actions](/producten/productacties).

### Permission [#recht]

What a user may do in Tillor, for example edit products or restore invoices. You give permissions per user or through a group. A denial through a group always wins. See [Editing permissions](/gebruikers/organisaties#rechten-bewerken) and [Group permissions](/gebruikers/groepen#groepsrechten).

### Reservation [#reservering]

A booking for a single stay on a terrain, with arrival and departure. A reservation is not the same as an occupation. See [Reservations](/reserveringen).

### Task [#taak]

A piece of work for yourself or a colleague, with among other things a deadline, subtasks and linked customers or terrains. You look at tasks in views. See [Tasks](/taken).

### Tablet [#tablet]

The device at reception that runs the Tillor app, for example to have a customer sign a contract or mandate. You find tablets, kiosks and phones where someone is signed in under **Settings**. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken).

### Terrain [#terrein]

A place in your park that you rent out or plan stays on, with a name and possibly meters. You link meters to a terrain, and customers get there through an occupation or reservation. See [Terrains](/terreinen).

### Terrain type [#terreintype]

A classification of your terrains, such as **Spot**, **Chalet** or **Camper pitch**. You use the type to filter the list, colour the map and in automations. See [Terrain types](/terreinen#terreintypes).

### Access method [#toegangsmethode]

The way a customer gets through an access point: licence plate recognition, an NFC tag or a QR code. You manage them on the customer under the **Access Control** tab. See [Access control](/toegangscontrole).

### Access point [#toegangspunt]

A barrier, gate or electronic door where access is checked. You can open and close an access point from Tillor and see in the log who passed. See [Access control](/toegangscontrole).

### Trigger [#trigger]

The start of an automation: the event, the time or the message that makes it start. A trigger can have a filter, so the automation only starts when something is true. See [Triggers](/automatiseringen/triggers).

### Consumption batch [#verbruiksbatch]

A period of meter consumption for one customer and one meter, with a start and end reading. The app calls this a **Consumption period**, and this manual also uses consumption batch. See [Consumption batches](/meterbeheer/consumptie-batches).

### View [#weergave]

A saved way of looking at your tasks, for example **Open tasks** or **Maintenance**. Each view appears as a tab at the top of the Tasks page. See [Views](/taken/weergaven).

### Seal [#zegel]

Your organisation's digital signature with which Tillor closes a signed PDF. If anything in the file changes afterwards, a PDF reader reports it. A timestamp goes with it. See [Seal and timestamp](/handtekeningen/bewijs-en-geldigheid#zegel-en-tijdstempel).

## See also [#zie-ook]

<Cards>
  <Card title="In practice" href="/praktijk" description="Four worked examples that combine several modules" />
  <Card title="Controllers: glossary" href="/controllers/lexicon" description="Technical terms around controllers" />
</Cards>


# Data and backups (/en-GB/gegevens-backups)

Tillor automatically makes backups of your organisation's data. You do not need to set anything up and you do not see them in Tillor. If you need data from the past or something has gone wrong, Tillor support restores an earlier state for you. This is how you ask for that, and how far back you can go.

<Callout type="info" title="Good to know">
- Backups go back to the first past calendar month, with one archive per month. The details are in the table below.
- You do not restore a backup yourself: this always goes through Tillor support.
- You cannot download or view a backup yourself.
</Callout>

Before you start: know which data you need and from which time or month.

## How long does Tillor keep backups? [#hoe-lang-bewaart-tillor-back-ups]

Tillor keeps three kinds of backups side by side. Together they give you a recent restore point and a longer history.

| Period | What you can find |
|--------|-------------------|
| **Last 48 hours** | A backup every 4 hours, for restoring to a recent point in time |
| **Last 14 days** | One backup per night |
| **Every past calendar month** | One monthly archive per month, with no automatic deletion |

The current calendar month only has the nightly backups of the last 14 days. Once a month is over, one backup of that month is kept as the monthly archive.

These periods apply to all organisations. If Tillor changes the policy, we will update this page.

## Having a backup restored [#een-back-up-laten-terugzetten]

You do not restore a backup yourself in Tillor. Tillor support does it together with you, so your current data is not overwritten by accident.

<Steps>
<Step>
### Gather what you want to get back [#verzamel-wat-je-wilt-terughalen]
Decide which data you need, such as invoices, customers or reservations. Note the time or period you want to go back to, for example "yesterday around 14:00" or "March 2026".
</Step>
<Step>
### Contact Tillor support [#neem-contact-op-met-tillor-support]
Email support@tillor.eu and state your organisation name, which data you want back and the desired time or period.
</Step>
<Step>
### Agree on what exactly comes back [#overleg-wat-er-precies-terugkomt]
Tillor support finds the backup that fits your request and discusses with you what will happen before the restore starts.
</Step>
</Steps>

<Callout type="warn" title="Please note">
Restoring can bring data back to an earlier state. Everything you entered after the chosen time may disappear as a result. Always discuss this with Tillor support first.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor support finds the right backup and discusses with you what comes back before the restore starts.
- During the restore your organisation is in maintenance mode and only Tillor staff can access it. Afterwards everything is available again.
- Data you entered after the chosen time may have disappeared. So always discuss it first.

## Problems? [#problemen]

<Accordions>
<Accordion title="I want to download or view a backup myself">
That is not possible in Tillor. Backups are only available to Tillor support. Ask support to look up the data you need.
</Accordion>
<Accordion title="I want data from more than a month ago">
For earlier months Tillor keeps one backup per calendar month. So you can go back to a month, but not to a particular day or hour in that month. For the last 14 days it can be done per day, for the last 48 hours per 4 hours.
</Accordion>
<Accordion title="Tillor is not available during the restore">
During a restore your organisation is in maintenance mode and only Tillor staff can access it. Agree a moment with Tillor support that suits you.
</Accordion>
<Accordion title="I accidentally deleted an invoice or customer">
Email Tillor support with the name of the data and the time of deletion. First check the [activity log](/activiteitenlog) to see who changed what and when.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Getting started" href="/aan-de-slag" description="Set up your park step by step" />
  <Card title="Activity log" href="/activiteitenlog" description="See who changed what and when" />
</Cards>


# Signing in to Tillor (/en-GB/inloggen)

You sign in to Tillor with an account you already have with Microsoft, Google or Apple. Tillor has no password of its own: that provider takes care of your password. After signing in you choose your organisation and land on the dashboard. If this is your first day, continue to [Getting started](/aan-de-slag).

Before you start:

- You need a Microsoft, Google or Apple account.
- An administrator must first have invited you as a user with the same email address. If that has not happened, you will see **No organisations found**.

## Signing in [#inloggen]

<Steps>
<Step>
### Open Tillor [#open-tillor]
Go to the Tillor web application in your browser. If you are already signed in, Tillor takes you straight to your organisation.
</Step>
<Step>
### Choose your sign-in method [#kies-je-inlogmethode]
Click **Login with Microsoft**, **Login with Google** or **Sign in with Apple**. The method you last signed in with is marked **Last used**.
</Step>
<Step>
### Follow the provider's steps [#volg-de-stappen-van-de-provider]
You go to the sign-in screen of Microsoft, Google or Apple. With Microsoft and Google you choose which account to use. Then you return to Tillor.
</Step>
<Step>
### Choose your organisation [#kies-je-organisatie]
If you have access to more than one organisation, you see a selection screen. Find your organisation in the list and click **Open**. If you only have one, you go straight to the dashboard.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- You land on your organisation's dashboard. Tillor remembers your last sign-in method and marks it **Last used** next time.
- You only see the parts you have permissions for.
- Your session stays active on this device, for up to 30 days without use or until you sign out yourself.

## How does it all fit together? [#hoe-hangt-dit-samen]

One person has one Tillor account. You can link that account to several sign-in methods. An administrator adds you as a user to an organisation and gives you permissions. What you see afterwards depends on those permissions.

```mermaid
flowchart LR
  A[Je Microsoft-, Google- of<br/>Apple-account] --> B[Je Tillor-account]
  B --> C[Een of meer organisaties]
  C --> D[Jouw rechten<br/>bepalen wat je ziet]
```

<Callout type="info" title="Good to know">
- You stay signed in as long as you use Tillor. After 30 days without use you sign in again.
- A verification link for your email address is valid for 15 minutes. You can request a new email at most once every two minutes.
- Microsoft is always available as a sign-in method. Google and Apple may be missing, depending on your Tillor environment.
- You cannot unlink your last sign-in method.
</Callout>

## Giving a colleague access [#een-collega-toegang-geven]

An administrator with the right permissions invites colleagues.

<Requires permission="Manage user permissions" />

<Steps>
<Step>
### Open the users [#open-de-gebruikers]
Go to <UIPath>Support > Settings</UIPath> and choose **Users**.
</Step>
<Step>
### Invite the colleague [#nodig-de-collega-uit]
Click **Invite user**, enter the email address and click **Invite**.
</Step>
</Steps>

If a Tillor account with that email address already exists, the colleague is added straight away. Otherwise the colleague receives an invitation by email and becomes a member on their first sign-in. After that you set the permissions, see [Organisation](/gebruikers/organisaties). The colleague will not see anything useful until those permissions are set.

## Managing your own account [#je-eigen-account-beheren]

Click your name at the bottom of the menu and choose **Account**. There you find:

- **Email**: whether your email address is **Verified** or **Not verified**. If it says **Not verified**, you see the button **Verify email address**, see [Verifying your email address](#je-e-mailadres-verifiëren).
- **Linked platforms**: link Microsoft, Google or Apple to the same account with **Connect**, or remove a link with **Disconnect**. You cannot unlink your last sign-in method.
- **Active sessions**: see which devices you are signed in on. With **Sign out** you end one session, with **Sign out all other devices** all the others.
- Your phone number and the language of your account.

You stay signed in as long as you use Tillor. After 30 days without use you sign in again. To sign out, choose **Sign out** in the menu under your name.

## Verifying your email address [#je-e-mailadres-verifiëren]

Tillor takes your email address from the provider you first signed in with. Google and Apple pass on that the address is yours. Microsoft usually does not, and then your address shows as **Not verified** on the **Account** page.

As long as your address is not verified, Tillor does not link a second sign-in method to your account when you sign in. If, for example, you sign in with Google for the first time while your account was created with Microsoft, you see the message that the address already belongs to an account that has not been verified yet. Verify your address once, and after that it works.

<Steps>
<Step>
### Request the verification email [#vraag-de-verificatiemail-aan]
If you are signed in, click **Verify email address** on the **Account** page. If you are not signed in and got the message on the sign-in page, enter your email address there and click **Send verification email**. That page always gives the same confirmation, even if no account with that address exists.
</Step>
<Step>
### Open the email [#open-de-e-mail]
You receive an email with the subject **Verify your email address for Tillor**. Click **Verify email address**. The link is valid for 15 minutes; if it has expired, simply request a new one.
</Step>
<Step>
### Sign in [#log-in]
After clicking you come back to the sign-in page or your account page. Sign in with the method of your choice. From now on Tillor links a new sign-in method with the same email address to your account.
</Step>
</Steps>

You can request a new verification email at most once every two minutes. If you do not want to wait for the email, a signed-in user can also link a second method straight away under **Account > Linked platforms**.

## API keys for integrations [#api-sleutels-voor-koppelingen]

For technical integrations you manage API keys on the **Account** page. Open **Developers** in your profile menu and click **Go to API Keys**, or go to **Account** > **API Keys**. See [Developers](/ontwikkelaars) for the integration documentation.

<DocScreenshot src="/screenshots/http/api-keys-nav.png" alt="Account - API Keys section" />

## Problems? [#problemen]

<Accordions>
<Accordion title="You see No organisations found">
Your account exists, but is not linked to an organisation yet. Ask an administrator of your organisation to invite you with the same email address as that of your Microsoft, Google or Apple account.
</Accordion>
<Accordion title="You see that the email address already belongs to an account that has not been verified yet">
A Tillor account with this address already exists, created with a different sign-in method, and that address has not been verified yet. Under the message, enter your email address and click **Send verification email**, or sign in with the method you used before and click **Verify email address** on the **Account** page. See [Verifying your email address](#je-e-mailadres-verifiëren).
</Accordion>
<Accordion title="The verification link has expired or is not valid">
A verification link works for 15 minutes. Request a new one on the sign-in page or the **Account** page and use the most recent email.
</Accordion>
<Accordion title="The account could not be linked">
This account is already linked to another user, or the email address does not match your current account. Use the same email address, or sign in with the account that is already linked and unlink it there first.
</Accordion>
<Accordion title="The sign-in session has expired">
Signing in took too long or the page was open too long. Click your sign-in method again and complete the steps more quickly.
</Accordion>
<Accordion title="I do not see everything my colleague sees">
What you see depends on your permissions. Ask an administrator to adjust your permissions, see [Organisation](/gebruikers/organisaties).
</Accordion>
<Accordion title="You get a different error message">
Try again. If it fails again, email support@tillor.eu and pass on the message.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Getting started" href="/aan-de-slag" description="Set up your park step by step" />
  <Card title="Users" href="/gebruikers" description="User permissions and organisation settings" />
</Cards>


# Vraag het Tillie (/en-GB/vraag-het-tillie)

Tillie is de assistent van deze handleiding. Je stelt een vraag zoals je ze aan een collega zou stellen, bijvoorbeeld "Hoe maak ik een creditnota?". Tillie zoekt de pagina's op die erover gaan, leest ze en antwoordt in een paar zinnen of stappen, met een link naar elke pagina die ze gebruikte. Zoek je een pagina waarvan je de naam al kent, dan is de [zoekfunctie](#zoeken-of-tillie) bovenaan sneller.

<Callout type="info" title="Goed om te weten">
- Tillie antwoordt uit deze handleiding. Over je eigen klanten, facturen of meters weet ze alleen iets als je haar [toegang tot je account](#tillie-in-je-account-laten-kijken) geeft.
- Ze antwoordt met AI en kan zich vergissen. Controleer een belangrijke stap op de pagina waar ze naar linkt.
- Ze antwoordt in de taal waarin je de handleiding leest.
- Zet geen persoonlijke gegevens van klanten in je vraag. Die heeft Tillie niet nodig.
</Callout>

## Een vraag stellen [#een-vraag-stellen]

<Steps>
<Step>
### Open Tillie [#open-tillie]
Klik rechtsonder op **Vraag het Tillie**, of druk op **⌘I** (Mac) of **Ctrl+I** (Windows). Tillie opent aan de rechterkant; op een telefoon vult ze het scherm. Met **Groter** maak je het venster breder.
</Step>
<Step>
### Stel je vraag [#stel-je-vraag]
Typ je vraag onderaan en druk op **Enter**. Met **Shift+Enter** begin je een nieuwe regel. Weet je niet goed hoe te beginnen, kies dan een van de voorbeeldvragen. Een vraag is maximaal 1.000 tekens lang.

Ben je niet aangemeld bij Tillor, dan controleert Tillie bij je eerste vraag dat je geen robot bent. Meestal merk je daar niets van; soms vraagt een vakje om een klik.
</Step>
<Step>
### Volg wat Tillie opzoekt [#volg-wat-tillie-opzoekt]
Boven het antwoord zie je wat Tillie doet: **Zocht naar** met de zoekwoorden en **Las** met de titel van elke pagina die ze opende. Daarna verschijnt het antwoord, woord voor woord. Met de stopknop rechts in het invoerveld breek je een antwoord af.
</Step>
<Step>
### Open de bronnen [#open-de-bronnen]
Klik op **bronnen gebruikt** om de pagina's te zien waar het antwoord op steunt, en klik een titel om de pagina te openen. Links in het antwoord zelf werken ook. Tillie blijft open terwijl je leest, behalve op een telefoon.
</Step>
</Steps>

## Tillie in je account laten kijken [#tillie-in-je-account-laten-kijken]

Ben je aangemeld bij Tillor, dan kan Tillie ook vragen over je eigen gegevens beantwoorden, zoals "Welke facturen van de familie Peeters staan nog open?" of "Wat was de laatste meterstand van plaats 12?". Daarvoor geef je haar eerst toegang.

<Steps>
<Step>
### Geef Tillie toegang [#geef-tillie-toegang]
Open Tillie. Bovenaan staat **Mag Tillie in je account kijken?**. Ben je lid van meer dan één organisatie, kies dan de organisatie. Klik **Toegang geven**.
</Step>
<Step>
### Stel je vraag [#stel-je-vraag-1]
Bovenaan staat nu **Tillie leest mee in** met de naam van je organisatie. Stel je vraag zoals altijd. Wat Tillie in je account opzoekt, zie je boven het antwoord: **Zocht in je account naar** en **Las** met wat ze bekeek.
</Step>
</Steps>

<Callout type="info" title="Wat Tillie mag">
- Tillie kan alleen **lezen**, en alleen wat jij zelf mag zien in die organisatie. Ze kan niets wijzigen, verwijderen of versturen.
- De toegang geldt 30 dagen. Met **Intrekken** stop je ze meteen.
- Geven en intrekken van de toegang staan in de [activiteitenlog](/activiteitenlog#beveiligingsgebeurtenissen) van je organisatie.
- Wat Tillie leest, gaat naar het taalmodel dat haar antwoord schrijft, net als bij de AI-assistent in de inbox. Het wordt niet bewaard om modellen te trainen.
</Callout>

## Een wijziging bevestigen [#een-wijziging-bevestigen]

Vraag je Tillie iets te veranderen, bijvoorbeeld "Zet factuur 2026-0142 terug naar concept", dan doet ze dat niet zelf. Ze stelt het voor in een kaart **Voorgestelde wijziging** met wat er zal gebeuren en welke velden veranderen, met hun nieuwe waarde.

- Klik **Bevestigen** om de wijziging uit te voeren. Tillor voert ze uit met jouw rechten, alsof je ze zelf deed, en toont daarna **Uitgevoerd.** of waarom het niet lukte.
- Klik **Annuleren** als je de wijziging niet wil. Er gebeurt dan niets.
- Een voorstel verloopt na 10 minuten. Vraag het dan opnieuw.

Elke bevestigde wijziging staat in de [activiteitenlog](/activiteitenlog#beveiligingsgebeurtenissen) van je organisatie, en de wijziging zelf staat in de **Gebeurtenissen** van het record, op jouw naam met het label **Via Tillie** eronder ([meer](/activiteitenlog#wie-heeft-het-gedaan)).

## Wat gebeurt er daarna? [#wat-gebeurt-er-daarna]

- Je gesprek blijft bewaard zolang het tabblad open is, ook als je naar een andere pagina gaat. Een vervolgvraag mag dus naar het vorige antwoord verwijzen ("En als de factuur al betaald is?"). Tillie onthoudt de laatste drie vragen met hun antwoord.
- Met **Nieuw gesprek** (het ronde pijltje bovenaan) begin je opnieuw. Sluit je het tabblad, dan is het gesprek weg.
- Onder elk antwoord laat je met een duim weten of het hielp. Zo zien we welke vragen de handleiding nog slecht beantwoordt.

## Hoeveel vragen kan je stellen? [#hoeveel-vragen-kan-je-stellen]

Tillie beantwoordt één vraag tegelijk. Daarnaast gelden grenzen, zodat de assistent beschikbaar blijft voor iedereen:

| Wie | Per minuut | Per dag |
|-----|------------|---------|
| Niet aangemeld | 5 vragen | 30 vragen |
| Aangemeld bij Tillor | 10 vragen | 100 vragen |

Op een netwerk dat je deelt met anderen, zoals de wifi van een kantoor of camping, geldt ook een grens voor iedereen samen. Heeft Tillie op een dag veel bezoekers geholpen, dan vraagt ze wie niet aangemeld is om zich aan te melden.

## Zoeken of Tillie? [#zoeken-of-tillie]

| Je wil | Gebruik |
|--------|---------|
| Een pagina openen waarvan je de naam kent, zoals "Mandaat" | De zoekfunctie bovenaan (**⌘K** of **Ctrl+K**) |
| Weten hoe je iets doet, in je eigen woorden | Tillie |
| Een antwoord dat meerdere pagina's combineert | Tillie |

## Problemen? [#problemen]

<Accordions>
<Accordion title="Ik zie Vraag het Tillie niet">
Tillie is nog niet voor iedereen beschikbaar. Staat de knop niet rechtsonder, gebruik dan de zoekfunctie bovenaan.
</Accordion>
<Accordion title="Je ziet Je stelde veel vragen kort na elkaar">
Je zit aan de grens per minuut of per dag. De melding zegt hoe lang je moet wachten. Ben je niet aangemeld, meld je dan aan bij Tillor: dan krijg je meer vragen per dag.
</Accordion>
<Accordion title="Je ziet Tillie beantwoordde vandaag al veel vragen van bezoekers">
De vragen voor bezoekers die niet aangemeld zijn, zijn voor vandaag op. Klik **Aanmelden bij Tillor** en stel je vraag opnieuw, of gebruik de zoekfunctie.
</Accordion>
<Accordion title="Je ziet Tillie is nu niet beschikbaar">
Tillie neemt even geen vragen aan. Gebruik de zoekfunctie bovenaan en probeer het later opnieuw.
</Accordion>
<Accordion title="Je ziet De controle of je geen robot bent lukte niet">
Herlaad de pagina en stel je vraag opnieuw. Blokkeert een extensie in je browser scripts of cookies, zet ze dan uit voor deze site.
</Accordion>
<Accordion title="Ik zie Mag Tillie in je account kijken? niet">
Dat staat er alleen als je aangemeld bent bij Tillor in dezelfde browser. Meld je aan en open Tillie opnieuw. Heb je al toegang gegeven, dan staat er **Tillie leest mee in**.
</Accordion>
<Accordion title="Je ziet Niet uitgevoerd bij een wijziging">
Tillor weigerde de wijziging, meestal omdat je er de rechten niet voor hebt of omdat het record intussen veranderde. De melding zegt waarom. Doe de wijziging dan in Tillor zelf.
</Accordion>
<Accordion title="Je ziet Verlopen bij een wijziging">
Je bevestigde niet binnen 10 minuten. Vraag Tillie de wijziging opnieuw voor te stellen.
</Accordion>
<Accordion title="Het antwoord klopt niet">
Open de bronnen onder het antwoord en controleer de stap op die pagina. Geef het antwoord een duim omlaag, zodat we het kunnen verbeteren.
</Accordion>
</Accordions>

## Zie ook [#zie-ook]

<Cards>
  <Card title="Zoeken in Tillor" href="/zoeken" description="Een klant, factuur of terrein vinden in de app" />
  <Card title="Begrippen" href="/begrippen" description="Alle termen in Tillor op een rij" />
  <Card title="Aan de slag" href="/aan-de-slag" description="Je eerste stappen in Tillor" />
</Cards>


# What's new (/en-GB/wat-is-nieuw)

Tillor gets an update almost every day. This page lists the changes you notice as an administrator. We leave out small improvements and bug fixes.

## November 2026 [#november-2026]

### Payments [#betalingen-november-2026]

- A refund that has been created at Mollie but not carried out yet now shows the payment as **Refund Pending** or **Partial Refund Pending**. The amount already counts in the invoice balance. See [Status labels](/betalingsverwerking/betalingen-bekijken#statuslabels).

### Tasks [#taken]

- Filter tasks by **Text**: show only tasks whose name or description does or does not contain a text, and add as many texts as you like (for example **Does not contain** `Verzekering vervallen:`). See [Filtering by text](/taken/filteren#filteren-op-tekst).
- Filters and view settings on the built-in view **All** can now be saved for the whole organisation, with the permission **Manage labels and shared views**. See [Saving or discarding changes](/taken/weergaven#wijzigingen-opslaan-of-verwerpen).

### Search [#zoeken]

- The search window shows the results by category, with the category of the best hit at the top and the three best hits per category. With the **Everything** button at the start of the search field, or with **⌥1** to **⌥9** (**Alt** on Windows), you search in one category, even before you type. At the bottom you find the shortcuts and the categories without results. See [Search](/zoeken).

### Manual [#handleiding]

- Tillie can now also look in your account: give her read access to your organization and ask about your own customers, invoices or meters. She proposes a change; it only happens when you confirm it. See [Let Tillie look in your account](/vraag-het-tillie#tillie-in-je-account-laten-kijken). In the activity log, such a change is in your name with the label **Via Tillie**.
- You now choose light or dark once: the manual follows the theme you chose in Tillor, and the other way round.
- New: [Ask Tillie](/vraag-het-tillie). Ask a question in your own words at the bottom right and Tillie answers from the manual, with the pages she used.
- The manual now also exists in other languages: choose your language at the top right. It opens automatically in the language you use in Tillor. A page that has not been translated yet shows the Dutch text.

### Website chat [#website-chat]

- A visitor can now send 10 messages per minute and 200 per day through the chat, and all visitors on one network together 30 per minute. Above that, the visitor is asked to wait a moment. This way a script cannot flood your inbox and Tillie's replies. See [Troubleshooting](/inbox/website-chat#problemen).

### Meters (ICY) [#meters-icy]

- Tillor now reads ICY through the new API v2. Under <UIPath>Settings > Integrations > ICY</UIPath>, enter the login for API v2 and choose your park's number in the list; without those details ICY meters are no longer updated.
- An ICY meter shows which **Module** is fitted at the spot (Campère or PRM) and, if ICY knows it, the **Module serial number**. If that serial number changes at ICY, it appears in the meter's **Activity**.
- The **ICY controllers** card in <UIPath>Park > Meters</UIPath> shows for each controller when ICY last saw it, and how many meters hang behind it. Alarms that ICY reports on a controller are now shown there too, and you get the same push notification for them as for a meter alarm. A controller with an alarm, or one that has been silent for more than an hour, is listed first. A controller carries the name of your meter cabinet (for example **MK6**) instead of ICY's number. See [ICY controllers](/meterbeheer/alarmen-en-status#icy-controllers).
- An ICY meter now also shows its **Controller** and the **Off time**. A different off time of the module appears in the meter's **Activity**.
- The list in <UIPath>Park > Meters</UIPath> has a **Module** column (Campère or PRM), and the Excel file from **Export all meters** has the column `module` on the ICY sheet.
- **Amperage** now only offers the values up to the maximum set at ICY for the module at that spot. Before, Tillor offered the park's whole list on every meter.
- Alarms from ICY get a fixed name in your own language, such as **Overcurrent** or **Voltage interrupted**, and the **Warnings** now show how many times the switching limit has already been used.

### Developers [#ontwikkelaars]

- **Not backwards compatible:** alarms are now called `integration-alarm` in the API and in events, because they can now also belong to an ICY controller. The events `meter-alarm:created` and `meter-alarm:resolved` have been replaced by [`integration-alarm:created`](/ontwikkelaars/events#integration-alarm-created) and [`integration-alarm:resolved`](/ontwikkelaars/events#integration-alarm-resolved), and the REST paths `/meter-alarms` by `/integration-alarms`. The old names no longer exist. Existing webhooks and automations have been converted to the new events automatically; adjust the event name and the path in your own code. The `meterId` field of an alarm can be empty; `icyControllerId` is then filled in.
- An OAuth client can now be limited to people of your organization, and further to groups and permissions: tick **Only people of (your organization) can sign in** in the client's dialog under <UIPath>Account > OAuth Clients</UIPath>. Meant for single sign-on into an external service. See [OAuth clients](/ontwikkelaars/oauth-clients).
- Every endpoint in the [API reference](/api-referentie) now shows under **Access** who may call it and which permission a member needs for it. An API key with scopes also needs that permission among its scopes. The [Event index](/ontwikkelaars/events) shows the same per event.

### API keys [#api-sleutels]

- An API key can now be limited to the permissions an integration needs: switch on **Limit to selected permissions** in the key dialog under <UIPath>Account > API Keys</UIPath>. A limited key can never do more than you can. See [Limiting permissions](/ontwikkelaars/http#rechten-beperken).

### Custom fields [#eigen-velden]

- A link field to meters can be limited to the meters of the occupation's terrain, and every link field to a listable record can filter its options with your own TypeScript. Tillor refuses a record outside that restriction when saving. Short lists (fewer than 50 records) are shown by the choice list straight away, without first typing 2 characters. See [Filtering options](/eigen-velden/veldtypes#opties-filteren).
- The same filter can also give an option its own label and a heading in the choice list, by returning a text or `{ label, group }` instead of `true`. See [Custom labels](/eigen-velden/veldtypes#eigen-labels).

### Manual [#handleiding-1]

- New in the manual: [Terms](/begrippen), a glossary of all terms in Tillor, and [In practice](/praktijk), four worked examples that follow a whole way of working across the modules, such as taking on a seasonal customer or charging consumption.
- Every module now starts with what it is, what you need for it and what happens next, with a **Good to know** block and a **Problems?** list per task. New too are [Inviting users and giving permissions](/gebruikers/gebruikers-en-rechten), an overview of all [notification types](/communicatie/notificatietypes) and separate pages per task for [meters](/meterbeheer), [controllers](/controllers) and [printers](/printer).

### Signatures [#handtekeningen]

- Customers, contacts and external parties can now also sign a document on the tablet at the front desk. At their turn, click **Sign on tablet**, with a code or without a code if you have checked their identity yourself; the tablet shows their name in large letters, also for a SEPA mandate. See [On the tablet at the front desk](/handtekeningen/ondertekenen#op-de-tablet-aan-de-receptie).
- With **Send**, the editor checks everything in one go: a signer without a signature field, or a customer or contact without an email address and mobile number, is flagged straight away. See [I cannot send](/handtekeningen/handtekening-vragen#problemen).

### Bank transactions [#banktransacties]

- Click the (i) icon on a bank transaction to open its detail panel. From the action menu you create a task about it or copy a link that opens the panel straight away. See [Viewing bank transactions](/boekhouden/betalingsrapporten/betaalmethodes/ponto#banktransacties-bekijken).

### Products and invoices [#producten-en-facturen]

- Reverse-charge VAT is now a choice in **VAT %**, next to the rates: for EU services and subcontractors, and also intra-Community supply, export and exempt. The invoice gets the legal statement, booking asks for a VAT number where required, and the line goes into the right grid in Admisol. For Odoo, enter the name of the Odoo VAT per regime in the [export settings](/boekhouden/betalingsrapporten/boekhoudsystemen/odoo#btw-regimes); a scheduled price can also switch a product to a regime. See [Reverse-charge VAT and other regimes without VAT](/boekhouden/belasting#btw-verlegd-en-andere-regimes-zonder-btw).
- Enter amounts from before Tillor, such as old deposits, as an opening balance on a customer's account: by hand or with an import for all customers at once. They count towards the balance and the monitoring, but are not an invoice and do not go to the accounting. See [Opening balances from before Tillor](/producten/product-aanmaken#beginsaldi-van-voor-tillor).
- A product bundle is now code: every step has a product, a quantity and an optional **Formula** in TypeScript that, when the invoice is saved, decides whether the step is added, with which quantity, or exactly which lines (own description, price, access method). The formula reads the customer, occupation, terrain and main line, custom fields included, plus the lists of meters and access methods. The fixed choices per meter, NFC tag and dog are gone; what they did is in the manual as an example formula. See [Formula per step](/producten/bundel-velden#formule-per-stap).
- Monitor a customer's balance on a ledger, for example for deposits. Tillor shows the balance on the invoice and refuses an invoice that takes it below zero. With a separate permission you can book anyway, with a justification in the timeline. See [Monitoring the customer's balance](/producten/product-aanmaken#het-saldo-van-de-klant-bewaken).
- On a customer's **Invoicing** tab there is the new **Accounts** table: the balance per ledger on which something has been booked, with below it the booked invoices and the running account. If you have monitored ledgers, you only see those by default; with a filter you see them all. See [Monitoring the customer's balance](/producten/product-aanmaken#het-saldo-van-de-klant-bewaken).

### Invoices and payments [#facturen-en-betalingen]

- With **Part-payment link** in the menu of a booked invoice you create a payment link for part of the outstanding amount. See [Creating a link for a part payment](/facturen/betalingen-registreren#een-link-voor-een-deelbetaling-maken).
- A signed SEPA mandate is sealed, so a PDF reader shows any later change. See [SEPA mandate](/betalingsverwerking/mandaat).

### Users and permissions [#gebruikers-en-rechten]

- A group can allow or deny permissions for all its members; a denial always wins. In **Edit permissions** you see per permission whether it comes directly or through a group. See [Group permissions](/gebruikers/groepen#groepsrechten).

### Park and technology [#park-en-techniek]

- A controller can know several Wi-Fi networks, in an order you decide yourself. See [Controller settings](/controllers/settings).
- On a meter, **Consumption and trends** shows the consumption per hour for one day, with a new period picker. See [Meter management](/meterbeheer/meterstanden-en-trends#verbruik-en-trends-lezen).

### Tasks [#taken-1]

- Print a task on A4 or on a receipt printer from the task's menu; the printout also shows the linked items and blockers. The same menu has **Delete**, except for tasks that only an automation may complete. See [Task details](/taken/taakdetails#het-menu-van-de-taak).
- Add subtasks while you create a task. See [Creating a task](/taken/taakdetails#een-taak-aanmaken).
- A view can hide completed tasks after a day, week or month. See [Hiding completed tasks](/taken/indelingen#voltooide-taken-verbergen).

## October 2026 [#oktober-2026]

### Terrains [#terreinen]

- The **Calculated tariff** of a terrain now follows a formula that you write yourself per organisation under <UIPath>Settings > Terrain tariff</UIPath>, with the same `{terrain.…}` variables as in automations. You try the formula out on a terrain straight away, and every named part gets a column in the terrain export. The result is stored with the terrain and follows every change to the terrain or the formula. See [Tariff formula](/terreinen#tariefformule).

### Signatures [#handtekeningen-1]

- Have a PDF such as a rental contract signed online by customers, contacts, colleagues and external parties in turn. The signed PDF with evidence page goes to the customer's documents. See [Signatures](/handtekeningen).
- A signer can also type their signature or initials instead of drawing them. See [How someone signs](/handtekeningen/ondertekenen).
- In the editor you choose with **Fields for** who you place fields for, and you put a placed field on someone else's name with **Signer**. You place fields by tapping or dragging. See [Placing the fields](/handtekeningen/handtekening-vragen).

### Signing in [#inloggen]

- If your email address is still **Not verified**, you verify it with one click from the **Account** page or from the sign-in page. Only after that does Tillor link a second sign-in method to your account. See [Verifying your email address](/inloggen#je-e-mailadres-verifiëren).

### Automations [#automatiseringen]

- With the **Run code** step you write a piece of TypeScript on the variables of the flow, for example to decide which subtasks a task gets. You read the result in later steps as `{result}`. See [Run code](/automatiseringen/logica#code-uitvoeren).
- A flow can first **Sync bank transactions** and then send a payment reminder, so an invoice that has just been paid does not get a reminder. Save that automation from the office network, and Tillor remembers the IP for the bank connection. See [Sync bank transactions](/automatiseringen/acties/facturen-en-betalingen#banktransacties-synchroniseren).
- Switch off automatic reminders for a customer or for a single invoice. A reminder flow skips customers who already have that switched on. See [Disable automated reminders for customer](/automatiseringen/acties/facturen-en-betalingen#automatische-herinneringen-uitschakelen-voor-klant).
- With **Create task** you can set that only the flow completes the task. With **Delete task** you remove that task later. See [Tasks](/automatiseringen/acties/taken).
- On a task action you can switch on **Ask for confirmation**. The colleague then confirms the choice first, and after that the flow continues.
- Build automations yourself on a canvas: choose a trigger, add steps, conditions and waiting times and see per run what happened. See [Automations](/automatiseringen).
- An automation can have several triggers. Tillor blocks loops in which an automation keeps starting itself.
- Waiting can now be until a fixed time, a number of hours or minutes, or until your organisation closes.
- Start an automation on a date from a record, with a scheduled trigger or from your own system via an [incoming webhook](/ontwikkelaars/automatiseringen).
- With the **Ask for a decision** step you make the buttons on the task yourself, with your own colour and icon, optionally with a mandatory note or confirmation. Each button is an exit of the step. See [Ask for a decision](/automatiseringen/logica#vraag-om-een-beslissing).
- The trigger **A task action is chosen** starts an automation when someone chooses a linked button on a task. With an incoming webhook, **Ignore repeats** prevents the same call from starting the flow twice. See [Triggers](/automatiseringen/triggers).
- **Wait for an event** has an exit **Deleted** for when the flow's record disappears. See [Logic](/automatiseringen/logica#wachten-op-een-gebeurtenis).
- In the editor you test with a real record, put **Containers** around steps and restore an earlier version via **History**. See [Getting started](/automatiseringen/aan-de-slag#de-editor).

### Tasks [#taken-2]

- In the task list you see all linked records, and you filter by kind with **Linked to**. See [Filtering](/taken/filteren).
- Task emails show a preview of the task. You also find tasks via [Search](/zoeken).
- Before a private task becomes visible to the whole organisation, Tillor asks whether you want to make it public. See [Private tasks](/taken/prive-taken).
- Private tasks, a calendar view and a timer that keeps running while you carry on working. See [Tasks](/taken).
- Share a view as a read-only page or as a calendar link. See [Sharing tasks](/taken/delen).
- The waiting statuses have been merged into a single status **Waiting for reply**.
- Assign a task to a group, and share a view with groups of colleagues. See [Who sees a view](/taken/weergaven#wie-ziet-een-weergave).
- A task can have choice buttons, optionally with a mandatory note or confirmation. See [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen).
- Paste a file into the task window to add it as an attachment. Custom fields of tasks are also in that window.

### Inbox [#inbox]

- The reminder email from the website chat now also opens the conversation on another device or in another browser. See [Reminder by email](/inbox/website-chat-instellingen#herinnering-per-e-mail).

### Notifications [#meldingen]

- Choose per notification whether Tillor reaches you by email or push. You set this under **Account** at **Notifications**, or for a colleague via **Notification settings** among the organisation members. See [Users](/gebruikers).

### Tablets and kiosks [#tablets-en-kiosken]

- Every tablet or kiosk has its own device page with remote actions, diagnostics, history and settings. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken).
- Kiosk lock, night mode and notifications per device for Android tablets.

### Invoices and payments [#facturen-en-betalingen-1]

- On an invoice line with a period, choose the terrain on the map. When booking, Tillor creates the reservation and checks the guest in, depending on the product. See [Invoices](/facturen/aanmaken-en-bewerken#periode-en-terrein-kiezen).
- Draft payment reports for the current day. See [Payment reports](/boekhouden/betalingsrapporten).
- If Mollie holds a balance reserve on a payout, Tillor books it as *Balance reserve* on the supplier Mollie instead of on the suspense account, and on release it drops off there again. See [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol#balansreserve).
- Customers get a reminder to sign their SEPA mandate before it expires.

### Customers and files [#klanten-en-bestanden]

- You view attachments, documents and Outlook emails in a single file viewer, without downloading. You can play videos; uploads may be up to 250 MB.
- The customer overview shows active and overdue stays. Automatic invoicing pauses at unusually high water consumption.
- On a terrain you see the history of occupations, with a link to the customer.

### Custom fields [#eigen-velden-1]

- Add fields yourself to customers, terrains, occupations, meters, tasks, products, documents, reservations and access methods, under <UIPath>Settings > Custom fields</UIPath>. You place them between the standard fields, make them appear under a condition and decide who sees or edits them. See [Custom fields](/eigen-velden).

### Products [#producten]

- Schedule a new price from a date with **Scheduled prices**; Tillor applies it on that day and emails you. The **VAT calculator** converts a price or adjusts it with a percentage. See [Scheduling a price change](/producten/prijzen-plannen).

### Customers [#klanten]

- At the top of a customer is the card with the most important details, with pinned comments. Birthdays of customers and partners are marked. See [Customer management](/klantenbeheer).
- You enter an address with **Street**, **No.** and **Box**, with address suggestions as you type. See [Customer management](/klantenbeheer#adres-invullen).

### Access Control [#toegangscontrole]

- For a QR pass you see which wallet it is in, and with **Sync wallet pass** you prepare the pass again. See [Access control](/toegangscontrole).

### Integrations [#integraties]

- Connect Partoo to pass your opening hours, seasons and exceptions on to your location automatically. See [Partoo](/integraties/partoo).

## September 2026 [#september-2026]

### Payments [#betalingen]

- You sign SEPA mandates in Tillor itself, remotely or on the tablet at the front desk. See [SEPA Mandate](/betalingsverwerking/mandaat).
- A new payment page with your own choice of payment method, QR code and forwarding to the Bancontact app. Tillor warns when a payment method has a disruption.

### Access Control [#toegangscontrole-1]

- New access method: PIN code. A PIN code can be converted automatically into a licence plate. See [Access control](/toegangscontrole#toegangsmethoden-beheren-via-het-klantprofiel).

### Tasks [#taken-3]

- Saved views with a filter builder, sharing with colleagues and a calendar feed per view. See [Views](/taken/weergaven).
- Dependencies between tasks, the priority **Urgent** and labels that you create inline.
- Link a task to several customers, or to terrains, meters, invoices and reservations.

### Park and communication [#park-en-communicatie]

- Colour terrains on the map by type and export the map as an A4 PDF. See [Map](/kaart).
- For Voys telephony: routing per customer and automatic voicemail. See [Voys Telephony](/communicatie/providers/voys).
- Export a customer's invoice overview to Excel.


# Searching in Tillor (/en-GB/zoeken)

With search you can find a customer, invoice, occupation, reservation, phone call, terrain, meter, task or payment report in one go, from any page. You do not have to go to the right section first. The result opens the right page directly.

<Callout type="info" title="Good to know">
- Under **All results**, Tillor fetches at most ten hits per category and shows the best three. Pick a category to see up to a hundred.
- For customers, Tillor also finds hits with a small typo, so "Jansen" also returns "Janssen".
- Notes on phone calls are encrypted and are not searched. Search by phone number.
- NFC tags and licence plates have no category of their own. You find them under **Customers**.
</Callout>

## Searching and opening a result [#zoeken-en-een-resultaat-openen]

<Steps>
<Step>
### Open the search window [#open-het-zoekvenster]
Click **Search** in the header (on a narrow screen, the magnifying glass), or press **⌘K** (Mac) or **Ctrl+K** (Windows). The same shortcut closes the window again.

<DocScreenshot src="/screenshots/zoeken/search-dialog-open.png" alt="Global search opened" />
</Step>
<Step>
### Type your search term [#typ-je-zoekterm]
The results appear as soon as you pause typing. They are grouped by category, and the category with the best hit is at the top: the top line is always the best hit. A good match in the title counts for more than a match in the description. Each category shows its three best hits, and **Show … more** opens the whole category. At the bottom you see which categories found nothing.

<DocScreenshot src="/screenshots/zoeken/search-results.png" alt="Search results for Jonas by category, with the category of the best hit at the top" />
</Step>
<Step>
### Limit to one category (optional) [#beperk-tot-één-categorie-optioneel]
To search only one kind of data, choose it with the **Everything** button at the start of the search field, for example **Customers**. You can do this before or after typing; the search field then shows **Search in Customers…**. Clicking the name of a category in the results works too.

With the keyboard:
- **Shift+Tab** opens the list of categories.
- **⌥1** to **⌥9** (**Alt+1** to **Alt+9** on Windows) picks a category straight away, in the order of that list. The number is also shown next to the name of each category in the results.
- **Tab** steps through the categories that have results.

Back to everything: choose **Everything** in the list, or press **Backspace** in an empty search field.
</Step>
<Step>
### Open the result [#open-het-resultaat]
Use the arrow keys to choose and press **Enter**. With **Ctrl+Enter** (**⌘+Enter** on Mac) the result opens in a new tab. Clicking with the mouse works too. **Escape** closes the window.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The chosen result opens the customer, invoice or other page in the same tab. With **Ctrl+Enter** (**⌘+Enter** on Mac) it opens in a new tab.
- Nothing changes in your data: searching only reads.
- Each result shows what it was found on, for example **Phone:** or **Invoice:** with the value that matches.

## What Tillor searches [#wat-tillor-doorzoekt]

| Category | What you can search on |
|-----------|-----------------------|
| **Customers** | Name, customer number, email, phone, address and town, VAT number, remarks, contact persons (name, email, phone) and access methods such as an NFC card or licence plate |
| **Invoices** | Invoice number (with or without prefix, year and separators), total amount, the ID from the invoice link and the notes (public and internal) |
| **Occupations** | Terrain name, the customer's first and last name and the occupation ID |
| **Reservations** | Reservation number (for example `RES/2026/0001`, with or without prefix and year, or compact `20260001`), note, customer name and the ID from the link |
| **Phone calls** | Incoming and outgoing number, call ID and external reference |
| **Terrains** | Name, description, ID and the gas meter number of the terrain |
| **Meters** | Name, serial number and ID of the meter |
| **Tasks** | Title, description and ID. A hit also shows the linked customer or terrain |
| **Payment reports** | Report number |

<Callout type="info" title="NFC and licence plate">
There is no separate category for NFC tags. NFC cards and other access values belong to **Customers** and show up there as soon as they match your search term.
</Callout>

## How many results do you see? [#hoeveel-resultaten-zie-je]

If a category has ten or more hits, **10+** appears next to the name of that category. In the overview you see the three best hits per category. Pick the category, or click **Show … more**, to see up to a hundred hits. For reservations and invoices, the tolerance for typos works mainly on numbers and notes.

## Search tips [#zoektips]

- **Licence plate, NFC or QR code**: search for the value stored on the customer. You find the customer under **Customers**.
- **Invoice or reservation number**: type the number as it appears on the document, or part of it. For `RES/2026/0042`, `2026/0042` and `20260042` work too.
- **Amount**: you can also find an invoice by its total amount, for example `120,50`.
- **Who is where**: under **Occupations**, search by the name of the terrain or of the customer.
- **Partial names**: for customers, part of the name is usually enough. For reservations, a word from the note helps.

## Problems? [#problemen]

<Accordions>
<Accordion title="You see No results found">
Check the spelling and try a shorter part of the term. If you picked a category, Tillor only searches in that one. If there are results in another category, the window says so. Choose **Everything** with the button at the start of the search field, or click **Remove filter**.
</Accordion>
<Accordion title="You see Search unavailable">
Something went wrong during the search. Click **Retry**. If it keeps going wrong, check the [system status](https://status.tillor.eu).
</Accordion>
<Accordion title="I cannot find a customer by licence plate or NFC card">
Search for the exact value as it is stored on the customer. You find the customer under **Customers**, not in a separate category.
</Accordion>
<Accordion title="I cannot find a reservation">
Type the number as it appears on the document, or part of it: for `RES/2026/0042`, `2026/0042` and `20260042` work too. Otherwise, search by the customer's name.
</Accordion>
<Accordion title="You cannot find a phone call by its note">
Notes on phone calls are stored encrypted and therefore cannot be searched. Search by phone number.
</Accordion>
<Accordion title="The shortcut does not work">
Some browsers or extensions use Ctrl+K or ⌘K themselves. Then click **Search** in the header.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" description="Manage customers" />
  <Card title="Occupations" href="/bezettingen" description="A customer on a terrain" />
  <Card title="Reservations" href="/reserveringen" description="Manage reservations" />
  <Card title="Invoices" href="/facturen" description="Manage invoices" />
</Cards>


# Activity log (/en-GB/activiteitenlog)

In the activity log you see what has changed in Tillor, when, and by whom. You open it on a customer, invoice, task or other record, and centrally via **Audit log** if you have the permission for it. It is a read-only trail that you use to check or prove something.

<Callout type="info" title="Good to know">
- An entry cannot be edited or deleted
- An export covers the last 30 days by default, and at most one year
- Opening the same document repeatedly within ten minutes is recorded once
- Times are shown in your time zone
- Actions by an automation, an API key or the system are in there too, with the kind of actor next to them
</Callout>

## Viewing the activity log [#activiteitenlog-bekijken]

In the app this is usually called **Events** or **Activity**, depending on where you are. Anyone with the *View audit log* permission can also open a central overview via *Audit log* in the sidebar (above Settings), with filters on user, event type and date.

| Where | Navigation | Label in the app |
|------|-----------|-----------------|
| Customer (all related activity) | *Customers > customer > Events* | Events |
| Invoice | *Administration > Invoices > invoice* | Events |
| Reservation | *Customers > customer > Reservations > reservation* | Activity |
| Terrain | *Park > Terrains > terrain* | Events |
| Meter | *Park > Meters > meter* | Activity |
| Product | *Administration > Products > product* | Events |
| Task | *Tasks > task* or *Customers > customer > Tasks > task* | Activity |
| NFC tag | *Controllers > NFC tags > tag* | Activity |
| Tablet, kiosk or phone | *Settings > Tablets & kiosks > device* | History |
| Organisation (central) | *Audit log* (above Settings, *View audit log* permission) | Audit log |
| Payment report | *Administration > Payment reports > report* | Event Log |

For each activity you see in the timeline:

- **Title** - kind of event (e.g. "Invoice booked", "Customer updated")
- **User** - the colleague who performed the action (or Tillor for automatic actions)
- **Time** - date and relative time
- **Description** - additional details; sometimes with links to related invoices or other records
- **Before / after** (sometimes) - when creating, changing or deleting customer, contact, invoice, payment, payment mandate, payment group, document, access method, access point, controller, terrain, meter, meter reading, product, occupation, task or comment data, plus scanning, assigning or unlinking an identity document and changes to settings, membership rights, invoicing or NFC: which fields were changed. PIN codes of access points and personal data of an identity document are not kept in the log
- **Attachments** (sometimes) - downloadable files, for example for failed integrations
- **Login / logout** - when a colleague logs in or out, visible in the central audit log overview
- **OAuth apps and consent** - creating, changing, deleting or rotating the secret of OAuth apps, plus consent given, refused or revoked; visible in the central audit log overview. Client secrets are not kept in the log
- **Management and security** - changes to the organisation profile (name, legal details, VAT, IBAN, logo, maintenance mode), invitations and new members, personal API keys (create, change, renew, delete), ended sessions, webhooks, automations, colleague groups, terrain types, meter cabinets, controller groups, installed or removed integrations and the acceptance of the data processing agreement; visible in the central audit log overview. Keys, webhook secrets and integration settings are not kept; for an integration you only see which settings were changed
- **Access to personal data** - who opened or downloaded a document, viewed or downloaded the images or files of an identity document, or opened the PDF of an invoice or sent it to the tablet. Opening repeatedly within ten minutes is recorded once; every download of an identity document is recorded separately

## Activity per record [#activiteiten-per-record]

On detail pages you see a timeline with the activity for that record. On the **Events** tab of a customer you find all activities linked to that customer (invoices, payments, occupations, etc.).


<DocScreenshot src="/screenshots/activiteitenlog/customer-events.png" alt="Events on the customer profile of Jonas Maes" />

For **reservations** this includes creating, checking in and checking out, cancellations and related reversals, and updating reservation details.

For **payment groups** you also see which payments were added to or removed from a group, and for **controllers** which adoption requests were approved or rejected.

For **payment reports** this includes creating the report, finalising a draft report and sending it to the accounting system.

For **signing requests** you see every step: created and changed, sent, link (re)sent, reminded, signing page opened, code sent or entered incorrectly, signed, refused, reset to draft, cancelled, expired and completed. See [Evidence and validity](/handtekeningen/bewijs-en-geldigheid).

For **external notifications** you see when a linked system updated or deleted a notification it had registered.

<Callout type="info">
The activity log is read-only. Entries cannot be edited or deleted.
</Callout>

## Who did it? [#wie-heeft-het-gedaan]

Next to the user, every line also shows **what kind of actor** performed the action: a logged-in user, an API key, an OAuth connection, an automation, the Tillor connector or the system itself. For an API key or OAuth connection, the id of that key or connection is in the details, so that with a leaked key you can see exactly what was done with it. If it says **Unknown**, Tillor could not determine the actor; that is deliberately something different from "System".

A change you confirm through [Tillie](/vraag-het-tillie#tillie-in-je-account-laten-kijken) is in your name, with the label **Via Tillie** below it. That way you always see which changes the assistant carried out for someone, just as an impersonated action shows who was really behind it.

## Security events [#beveiligingsgebeurtenissen]

Failed sign-ins, rejected API keys and OAuth tokens, refused access (missing permissions), exceeded request limits and a Tillor administrator opening your organisation are also shown in the activity log, with IP address and browser. Members with the **Security alerts** permission receive a notification every hour when webhooks, API keys or automations have been changed or when access has been repeatedly refused.

The access you give [Tillie](/vraag-het-tillie#tillie-in-je-account-laten-kijken) to your account or revoke, and every change you confirm through Tillie, are listed here too.

## Exporting for an audit [#exporteren-voor-een-audit]

With **Export** in the activity log you download all lines of the chosen period (by default the last 30 days, at most one year) as a ZIP with the data file (CSV or JSON Lines), a `manifest.json` with the number of lines, the period, who exported and the SHA-256 checksum of the data file, and a `CHECKSUMS.sha256` file that you can verify with `sha256sum -c`. The export itself is also recorded in the log, with the same checksum. Opening the full activity log and bulk exports of customer data (customer list, access log, terrains, meters) are logged as well.

All times are stored in **UTC** on servers with NTP time synchronisation and shown in your time zone; the export contains ISO 8601 times in UTC.

## What do you use the log for? [#waarvoor-gebruik-je-de-log]

- **Checking** - finding out which colleague booked an invoice or changed a customer
- **Troubleshooting** - finding out when an error occurred
- **Audits** - keeping a complete trail for internal or external checks

## See also [#zie-ook]

<Cards>
  <Card title="Users" href="/gebruikers" description="Manage users and permissions" />
  <Card title="Invoices" href="/facturen" description="View invoice history" />
</Cards>


# Getting started (/en-GB/automatiseringen/aan-de-slag)

On this page you build your first automation and get to know the editor, the screen where you draw flows. You need the **Manage automations** permission, or **All permissions**. See the [Overview](/automatiseringen) for the background.

## The overview [#het-overzicht]

Go to **Admin > Automations**. You see a list with one row per automation:

- the name and a label such as **2 issues** if something is still wrong with the flow (see [Problems and enabling](/automatiseringen/problemen))
- the description
- the chosen trigger, the number of steps and who made the automation (**by**)
- a series of small bars with the latest runs, with next to it the time of the last run or **Has not run yet**. A red bar is a failed run
- a switch to turn the automation on or off, and a menu with three dots

<DocScreenshot src="/screenshots/automatiseringen/overview.png" alt="Overview of automations with the list, the filters and the search field" />

At the top of the list you filter with **All**, **Enabled** and **Paused**. If an automation has issues, an **Issues** filter is added as well. With **Search automations** you search by name or description.

Click the name to open the editor. With the switch you turn an automation on or off. You cannot turn it on while there are issues. The **Automation actions** menu has two choices:

| Choice | What it does |
|---|---|
| **Duplicate** | Makes a copy named *[name] (copy)*. The copy is paused |
| **Delete** | Deletes the automation and its run history. Tillor asks for confirmation first |

Runs that are waiting in a delay at that moment stop when you delete the automation.

## Creating a new automation [#een-nieuwe-automatisering-maken]

Click **New automation**. A gallery with six starting points opens. You can adjust every step afterwards.

| Starting point | What it does |
|---|---|
| **Start from scratch** | An empty flow with only a trigger |
| **Check terrain after departure** | Creates a check task for the terrain when an occupation ends, with high priority and assigned to whoever ended the occupation |
| **Follow up unpaid invoices** | Waits until after the due date, sends a payment reminder and, a week later, creates a task to phone the customer if the invoice is still open |
| **Push reservations to another system** | For every new reservation, sends a payload of its own to your webhook endpoint and creates a task if delivery fails |
| **Check a meter that stopped counting** | Creates a task for reception when a meter stays still while the terrain was in use, with subtasks for checking on site |
| **Call the Tillor API** | Adds a comment to every new task through the Tillor API |

<DocScreenshot src="/screenshots/automatiseringen/gallery.png" alt="New automation gallery with the starting points" />

As soon as you choose, Tillor creates the automation and opens the editor. The automation is paused until you enable it.

## The editor [#de-editor]

The editor fills the whole screen and has three parts: the step list on the left, the canvas in the middle and the panel on the right. The name of the automation is at the top in the breadcrumb and you can change it there directly.

<DocScreenshot src="/screenshots/automatiseringen/editor.png" alt="Editor with the step list on the left, the canvas in the middle and the panel on the right" />

Hover over the ℹ markers for a short explanation of each part.

**Step list (left).** Find a step with **Search steps**. At the top is the **Tools** group with **Note** and **Container** (see [Notes and containers](#opmerkingen-en-kaders)). Below that are the steps in six groups, with **Documents** in between:

- **Logic**: the trigger **When this happens** and conditions, waiting, looking up and looping, such as **If / else**, **Switch**, **Delay**, **Open now?**, **Look up a record**, **For each** and **Ask for a decision**. See [Conditions, switches and delays](/automatiseringen/logica)
- **Tasks**: creating, finding and updating tasks
- **Documents**: finding and updating documents
- **Guests and messages**: messages to guests and colleagues, comments, the inbox, customers and reservations
- **Invoices and payments**: invoices, payment links, mandates and consumption
- **Access and devices**: access methods, barriers, power, NFC tags and tablets
- **Integrations**: **Send webhook** and **API request**

What each action does is described under [Actions](/automatiseringen/acties). At the bottom is **Request a step** for when you are missing one.

**Canvas (middle).** Here you see the flow. At the top is the trigger, below it the steps with lines between them. At the bottom left you zoom in and out.

**Panel (right).** At the top are the **Active** switch, a button such as **1 issue** when there are issues, a **Tidy up** button that lines the steps up neatly under each other (notes stay where they are) and a **Hide panel** button. If you hide the panel, **Show panel** brings it back. Below that you pick a tab:

| Tab | What you do there |
|---|---|
| **Configure** | Adjust the selected step. If nothing is selected, you can fill in a **Description** for the automation |
| **Test run** | Try out the flow, see [Testing and runs](/automatiseringen/testen-en-uitvoeringen) |
| **Runs** | Look back at what real runs did |
| **History** | View and restore earlier saved versions, see [Earlier versions](#eerdere-versies) |

If you have made changes, **Unsaved changes** appears at the bottom of the panel with the buttons **Revert** and **Save**. **Revert** puts the flow back to the last saved version. If the panel is hidden, those buttons are at the top right of the canvas.

As long as you have no step selected, the description is followed by who made the automation. Failed runs are emailed to that person, at most once an hour per automation.

On a phone the panel is hidden at first, so the canvas gets the whole screen. Tap a step or **Show panel** to open it.

### Adding and connecting steps [#stappen-toevoegen-en-verbinden]

There are four ways to add a step:

- Click a step in the list on the left. It appears in the middle of the canvas
- Drag a step from the list onto the canvas
- Click the plus under an exit that does not lead anywhere yet (**Add a step after "[exit]"**) and choose a step. The new step is connected straight away
- Drag a step onto a line. It then ends up between the two steps (**Insert a step here**)

To connect steps to each other, drag from the exit under a step to another step. The following applies:

- Each exit leads to one step. If you connect an exit again, the new line replaces the old one
- A line that would make a loop is refused. If there is a loop after all, you cannot enable the automation. A run stops as soon as it would repeat a step
- A step without an incoming line is never executed. Tillor reports that as an issue (**Not connected, so this step never runs.**)
- You can adjust, duplicate and add extra triggers from the list on the left. You cannot delete the last trigger. A trigger does not belong on a line: it starts a run of its own

Give a step a name of its own in the **Step name** field. That helps as your flow grows. With the **Duplicate step** and **Delete step** buttons at the top of the panel you copy or delete the selected step.

### Notes and containers [#opmerkingen-en-kaders]

With a note you explain on the canvas what part of the flow does, for example why a condition is there. A **Container** is a dotted line with a name that you put around a group of steps.

- In the **Tools** group, click **Note** or **Container** and type your text
- Drag the note or container to the steps they explain. Select them to make them larger or smaller with the corner handles
- Delete a note with **Delete note** or a container with **Delete container**, or select them and press Delete
- Notes and containers are never executed and do not count towards issues. You can place at most 50 of them together. They are kept with **Save**, just like the steps, and Ctrl/Cmd + Z undoes a change

### Earlier versions [#eerdere-versies]

Every time you save a change, Tillor keeps the previous version. On the **History** tab you see the versions with what changed, for example **1 step added** or **Layout or connections changed**, and by whom or what the change came (for example **Via the API**). With **Restore** you put a version on the canvas. That counts as an unsaved change: save to keep the version, or undo.

### Keyboard shortcuts [#sneltoetsen]

| Key | What it does |
|---|---|
| Ctrl/Cmd + S | Save |
| Ctrl/Cmd + Z | Undo |
| Ctrl/Cmd + Shift + Z or Ctrl/Cmd + Y | Redo |
| Ctrl/Cmd + C, Ctrl/Cmd + V | Copy and paste selected steps |
| Ctrl/Cmd + D | Duplicate selected steps |
| Ctrl/Cmd + A | Select all |
| Delete or Backspace | Delete selected steps or lines |
| Esc | Clear the selection |

## Saving and enabling [#opslaan-en-inschakelen]

Tillor does not save automatically. Click **Save** (or press Ctrl/Cmd + S) to keep your changes. The button is active as soon as something has changed and the name is not empty.

<Callout type="warn">
If the automation is on, you can only save when there are no issues left. A running flow must always stay valid. Fix the issues, or pause the automation first.
</Callout>

With the **Active** switch you turn the automation on. That also saves the flow straight away. The switch does not work while there are issues, with the explanation **Fix the open issues first**. After that, the automation starts on every matching event. It can take half a minute before a change takes effect everywhere.

If you later change an enabled flow, those changes only apply to new runs. Runs that are already in progress or waiting in a delay finish with the flow as it was when they started.

## Your first automation: a task after departure [#je-eerste-automatisering-een-taak-na-vertrek]

This example creates a task when an occupation ends.

1. Click **New automation** and choose **Check terrain after departure**
2. Click the trigger. Under **Event** it says `occupation:ended`
3. Click the **Create task** step. Adjust the **Title**, the **Description** and the **Priority**, or choose a board and a **Column** under **Add to board**
4. Open the **Test run** tab and click **Run test**. You see which steps the flow would go through
5. Click **Save** and turn **Active** on
6. End an occupation and look at the **Runs** tab to see what happened

## Requesting a step or event [#een-stap-of-gebeurtenis-aanvragen]

Missing a trigger, condition or action? Click **Request a step** under the step list. In the trigger's list of events there is also a link **Missing an event? Request it**.

1. Under **What do you need?** choose one of **A trigger or event**, **A condition or filter**, **An action** or **Something else**
2. Under **What should it do?** describe what you want to automate. Write at least 10 characters, at most 1000
3. Click **Send request**

Your request goes to the Tillor team, together with your name and the name of your organisation. You get a notification that the request has been sent.

## What happens next? [#wat-gebeurt-er-daarna]

- A new automation is paused. Nothing happens until you turn **Active** on.
- After enabling, the automation starts on every matching event. It can take half a minute before a change takes effect everywhere.
- Every start is a run. You see them on the **Runs** tab, with the status **Completed**, **Waiting**, **Failed** or **Canceled**.
- If a run fails, whoever made the automation gets an email, at most one per hour per automation.
- If you change a running flow, the changes only apply to new runs. What is already in progress or waiting finishes with the old flow.
- Tasks and comments that the automation creates are in the name of **Workflow**. See [Who runs an automation?](/automatiseringen/workflow-gebruiker).

## Problems? [#problemen]

<Accordions>
<Accordion title="The Active switch does not work">
Tillor shows **Fix the open issues first**. At the top of the panel, click the button with the number of issues and fix them. See [Problems and enabling](/automatiseringen/problemen).
</Accordion>
<Accordion title="I cannot save">
The **Save** button is only active when something has changed and the name is not empty. If the automation is on, you can only save without issues. Fix them or pause first.
</Accordion>
<Accordion title="My step is never executed">
Tillor reports **Not connected, so this step never runs.** Drag from the exit of an earlier step to this step.
</Accordion>
<Accordion title="I cannot connect a line">
A line that would make a loop is refused. A flow can only go forwards.
</Accordion>
<Accordion title="I do not see Automations in the menu">
The menu only appears if you have the **View automations** permission. Building and changing requires **Manage automations**. Ask an administrator to adjust your permissions.
</Accordion>
<Accordion title="The flow does not react to my action">
Go through the points under [Why does my automation not start?](/automatiseringen/veelgestelde-vragen#waarom-start-mijn-automatisering-niet).
</Accordion>
</Accordions>

## Next steps [#volgende-stappen]

<Cards>
  <Card
    title="Triggers"
    href="/automatiseringen/triggers"
    description="Choose when an automation starts"
  />
  <Card
    title="Actions"
    href="/automatiseringen/acties"
    description="Everything an automation can do"
  />
  <Card
    title="Example: checking a rental caravan"
    href="/automatiseringen/voorbeeld-nalopen"
    description="A complete flow with a lookup, a switch and subtasks"
  />
</Cards>


# Documents (/en-GB/automatiseringen/acties/documenten)

With these actions you work with a customer's documents, such as an insurance proof of payment. The type and the expiry date of a document are in the document details. In a flow you read them as `{document.userMetadata.documentType}` and `{document.userMetadata.insuranceExpiryDate}`.

## Find document [#document-zoeken]

Finds a customer's newest document. The step has two exits: **Found** and **Not found**.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer, for example `{document.customerId}` or `{customer.id}`. Required |
| **Type** | For example **Insurance payment proof**. Leave empty for any type |
| **Skip archived documents** | On by default |
| **Only documents that have not expired** | The expiry date must be after now. Documents without an expiry date then do not count. Off by default |

If several documents match, the step takes the newest. Via **Found**, later steps can use `{foundDocument.id}`, `{foundDocument.name}`, `{foundDocument.status}`, `{foundDocument.userMetadata.documentType}` and `{foundDocument.userMetadata.insuranceExpiryDate}`.

This way you can check, for example, when an insurance has expired, whether the customer already has a new, valid proof of payment: search with **Type** *Insurance payment proof* and **Only documents that have not expired** on, and only continue via **Not found**.

## Update document [#document-bijwerken]

Changes the type of a document, or archives or restores it. Empty fields stay as they are.

| Field | What you fill in |
|---|---|
| **Document** | The id of the document. `{document.id}` by default. Required |
| **New type** | Leave empty to keep the type |
| **Status** | **Active** or **Archived**. Leave empty to keep the status |

A type that requires an expiry date, such as **Insurance payment proof**, fails if the document has no expiry date. The action returns `{updatedDocument.id}`.


# Invoices and payments (/en-GB/automatiseringen/acties/facturen-en-betalingen)

These steps are in the **Invoices and payments** group. How the exits work is explained under [Exits of an action](/automatiseringen/acties#uitgangen-van-een-actie).

## Send payment reminder [#betalingsherinnering-versturen]

Sends the payment reminder of an invoice to the customer, just like the reminder button on the invoice does.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |

Note that the field expects the internal id of the invoice (`{invoice.id}`) and not the invoice number (`{invoice.displayId}`).

The step fails if:

- the invoice is not booked
- nothing is outstanding any more, so the invoice has already been paid
- the customer has no email address, phone number and complete postal address

The run then gets the status **Failed** and the rest of the flow is not executed. So put an **If / else** before the reminder that checks whether the invoice is still outstanding, as in the **Follow up unpaid invoices** template.

The step also skips an invoice if it has been taken out of automated reminders, or if the customer has **Exclude from automated reminders** turned on.

## Sync bank transactions [#banktransacties-synchroniseren]

Fetches new bank transactions and waits until the import has finished. Put this step before **Send payment reminder**, so that an invoice that has just been paid does not get a reminder. If Ponto is not connected, the step is skipped.

Save the automation from the office network. Tillor then remembers the IP that the bank connection needs. Without that IP the sync cannot start.

## Disable automated reminders for customer [#automatische-herinneringen-uitschakelen-voor-klant]

Turns on **Exclude from automated reminders** in the customer's invoicing settings. Reminder flows then skip all of that customer's invoices. A manual reminder remains possible.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer. Required |

## Disable automated reminders for invoice [#automatische-herinneringen-uitschakelen-voor-factuur]

Takes one invoice out of overdue reminder flows and automated reminders. Staff can still send a reminder manually.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. Required |

## Send invoice [#factuur-versturen]

Sends an invoice to the customer, in the same way as the send button on the invoice.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |

The step fails if the invoice is not booked or if the customer has no email address, phone number and complete postal address.

## Book invoice [#factuur-boeken]

Books a draft invoice, so that it gets its invoice number.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |

If the invoice is already booked, nothing happens and the flow continues via **Skipped**. After booking, the action returns `{bookedInvoice.displayId}`, the invoice number. You can use it in a message or task. Combine the step with **Send invoice** to book and send a draft invoice in one go.

## Print invoice [#factuur-afdrukken]

Prints an invoice, or shows it on the tablet at reception.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |
| **Where** | **A4 printer** (default), **Receipt printer** or **Tablet** |

You set up the printers under [Print settings](/printer/afdrukinstellingen). An invoice that you print a second time with this step is simply printed again.

## Create payment link [#betaallink-aanmaken]

Creates an online payment link for the amount that is still outstanding on an invoice.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |
| **Payment method** | **Let the customer choose** (default), **Bancontact**, **iDEAL**, **Credit card** or **Payconiq** |

The link only exists for a booked invoice with something still outstanding. If the invoice is not booked or already paid, the flow continues via **Skipped**. After that, the action returns `{paymentLink.url}`. Put it in a text, for example in a message via [Message a guest](/automatiseringen/acties/gasten-en-berichten#gast-een-bericht-sturen).

## Request SEPA mandate [#sepa-mandaat-aanvragen]

Sends a customer an email asking them to sign a SEPA mandate, or a reminder for a request that is still open. See [Mandate](/betalingsverwerking/mandaat) for the mandate itself.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer. `{customer.id}` by default. Required |
| **Send** | **A new request** (default) or **A reminder** |

A new request is skipped if one is already open. A reminder is skipped if there is no open request, or if the request has expired. In both cases the flow continues via **Skipped**.

## Collect by direct debit [#innen-via-domiciliëring]

Collects what is still outstanding on an invoice using the customer's active SEPA mandate.

| Field | What you fill in |
|---|---|
| **Invoice** | The id of the invoice. `{invoice.id}` by default. Required |
| **After days** | How many days Tillor waits before collecting. At 0 it is collected straight away. The maximum is 7 days, a higher number becomes 7. 0 by default |

The step collects the whole outstanding amount. If the invoice is not booked or already paid, or the customer has no active mandate, nothing happens and the flow continues via **Skipped**. If the customer has more than one active mandate, the step uses the newest.

## Invoice consumption [#verbruik-factureren]

Invoices a customer's outstanding meter consumption, books the invoice and sends it.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer. `{occupation.customerId}` by default. Required |
| **Send by e-mail** | On by default |
| **Send by text message** | Off by default |

If there is nothing outstanding to invoice, no invoice is made and the flow continues via **Skipped**. Otherwise the action returns `{consumptionInvoice.id}`. See [Meter management](/meterbeheer) for how consumption is tracked.

## Draft extension invoice [#conceptfactuur-voor-verlenging]

Creates a draft invoice that extends an occupation, ready to be checked. The invoice is not booked yet. It is the same kind of invoice you get with **Extend occupation (invoice)** on the customer profile.

| Field | What you fill in |
|---|---|
| **Occupation** | The id of the occupation. `{occupation.id}` by default. Required |
| **Add open consumption** | Puts the customer's outstanding meter consumption on the same invoice. Off by default |

The action returns `{extendInvoice.id}`. If you want to book and send the invoice straight away, then use **Book invoice** and **Send invoice** with `{extendInvoice.id}` as the invoice.


# Guests and messages (/en-GB/automatiseringen/acties/gasten-en-berichten)

These steps are in the **Guests and messages** group. How the exits work is explained under [Exits of an action](/automatiseringen/acties#uitgangen-van-een-actie).

## Message a guest [#gast-een-bericht-sturen]

Sends your own text to a customer by email, text message or WhatsApp. Use it for messages that have no fixed Tillor template, such as a welcome message on the day of arrival.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer, for example `{reservation.customerId}`. Required |
| **Subject** | Email only. Empty uses the name of your organisation |
| **Message** | The text, without formatting. Variables are filled in. Required |
| **Send by e-mail** | On by default |
| **Send by text message** | Off by default |
| **Send by WhatsApp** | Off by default |

Note the following:

- Customers who do not accept communication get nothing. The flow then continues via **Skipped**
- Outside the 24-hour window of WhatsApp, Tillor sends your text as an approved template. Inside that window it goes as a normal message
- If the customer does not exist, the step fails

## Notify colleagues [#collegas-verwittigen]

Sends colleagues a push notification, an email or both.

| Field | What you fill in |
|---|---|
| **Colleagues** | Choose one or more colleagues |
| **Also notify whoever caused the event** | Also notifies the colleague who caused the event. If the system caused the event, nobody is added |
| **Title** | The heading of the notification. Required |
| **Text** | The content of the notification |
| **Send as push notification** | On by default |
| **Send by e-mail** | Off by default |

The **Workflow** user never receives a notification itself. If there are no colleagues to notify, the step does nothing and the flow simply continues.

## Add a comment [#opmerking-toevoegen]

Places a [comment](/notities), in the name of **Workflow**.

| Field | What you fill in |
|---|---|
| **Comment** | The text of the comment. Required |
| **On** | **The event's records** (default) or **A task** |
| **Task** | Only with **A task**: the id of the task, for example `{createdTask.id}`. Required |

Note the following:

- Mention a colleague with `@{triggeredBy.name}({triggeredBy.id})`. That colleague then gets a notification, just as with a comment you type yourself. This only works if a colleague caused the event
- With **The event's records**, the comment goes on the customer, the invoice, the reservation, the payment, the terrain, the meter and the task that the event is about. If the event has none of those records, the step fails
- The action returns `{createdComment.id}`

## Reply in the inbox [#antwoorden-in-de-inbox]

Sends a reply in an inbox conversation, through the same channel the guest wrote with.

| Field | What you fill in |
|---|---|
| **Conversation** | The id of the conversation. `{threadId}` by default. Required |
| **Reply** | The text, without formatting. Variables are filled in. Anything longer than 4096 characters is cut off. Required |
| **Keep the AI assistant active** | Off by default |

Note the following:

- `{threadId}` exists for events about inbox messages, such as `inbox:message-created`
- That event applies to every new message, including your own reply. So first check that the message came from the guest, otherwise your reply starts the flow again. Put a [Look up a record](/automatiseringen/logica#record-opzoeken) on **Inbox message** with `{messageId}` before this step, and an **If / else** that checks whether `foundInboxMessage.direction` equals `INBOUND`
- By default your reply silences the [AI assistant](/inbox/inbox-ai-assistant) in that conversation, just as when a colleague replies themselves. With **Keep the AI assistant active** the assistant keeps talking. If the conversation is then archived, the step fails

## Tag or archive conversation [#gesprek-taggen-of-archiveren]

Gives an inbox conversation tags, archives it, or both.

| Field | What you fill in |
|---|---|
| **Conversation** | The id of the conversation. `{threadId}` by default. Required |
| **Add tags** | Choose one or more tags. They are added, existing tags stay |
| **Archive the conversation** | Off by default |

## Update customer [#klant-bijwerken]

Changes the status of a customer or adds a note. Other data of the customer stays unchanged.

| Field | What you fill in |
|---|---|
| **Customer** | The id of the customer, for example `{invoice.customerId}`. Required |
| **Status** | **Leave as it is** (default), **Default**, **Preferred**, **VIP**, **Warning** or **Blacklisted** |
| **Add to notes** | Text that goes on a new line under the existing notes. Empty adds nothing |

## Check in, check out or cancel [#inchecken-uitchecken-of-annuleren]

Puts a reservation into its next status.

| Field | What you fill in |
|---|---|
| **Reservation** | The id of the reservation. `{reservation.id}` by default. Required |
| **Action** | **Check in** (default), **Check out** or **Cancel** |

The reservation must be in the right status for that. **Check in** and **Cancel** work on a reservation with status **Booked**, **Check out** on a reservation with status **Checked in**. If it is in another status, nothing happens and the flow continues via **Skipped**.


# Overview (/en-GB/automatiseringen/acties)

Actions are the steps that really do something. You find them in the step list in the groups **Tasks**, **Documents**, **Guests and messages**, **Invoices and payments**, **Access and devices** and **Integrations**. The steps in the **Logic** group steer the flow itself. Those are described under [Conditions, switches and delays](/automatiseringen/logica). All actions are executed by your organisation's [**Workflow** user](/automatiseringen/workflow-gebruiker).

| Group | Action | What it does |
|---|---|---|
| Tasks | [Create task](/automatiseringen/acties/taken#taak-aanmaken) | Creates a task, optionally with subtasks, on a board and linked to a customer, terrain or invoice |
| Tasks | [Set task status](/automatiseringen/acties/taken#taakstatus-zetten) | Changes the status of an existing task |
| Tasks | [Find task](/automatiseringen/acties/taken#taak-zoeken) | Finds a task by title and continues via **Found** or **Not found** |
| Tasks | [Set task priority](/automatiseringen/acties/taken#taakprioriteit-zetten) | Raises, lowers or chooses the priority of an existing task |
| Tasks | [Update task](/automatiseringen/acties/taken#taak-bijwerken) | Renames a task, adds people or labels or moves the deadline |
| Tasks | [Delete task](/automatiseringen/acties/taken#taak-verwijderen) | Deletes a task, for example the task this flow created |
| Documents | [Find document](/automatiseringen/acties/documenten#document-zoeken) | Finds a customer's newest document and continues via **Found** or **Not found** |
| Documents | [Update document](/automatiseringen/acties/documenten#document-bijwerken) | Changes the type of a document, or archives or restores it |
| Guests and messages | [Message a guest](/automatiseringen/acties/gasten-en-berichten#gast-een-bericht-sturen) | Sends your own text to a customer by email, text message or WhatsApp |
| Guests and messages | [Notify colleagues](/automatiseringen/acties/gasten-en-berichten#collegas-verwittigen) | Sends colleagues a push notification or email |
| Guests and messages | [Add a comment](/automatiseringen/acties/gasten-en-berichten#opmerking-toevoegen) | Places a comment on the event's records or on a task |
| Guests and messages | [Reply in the inbox](/automatiseringen/acties/gasten-en-berichten#antwoorden-in-de-inbox) | Sends a reply in an inbox conversation |
| Guests and messages | [Tag or archive conversation](/automatiseringen/acties/gasten-en-berichten#gesprek-taggen-of-archiveren) | Adds tags to an inbox conversation or archives it |
| Guests and messages | [Update customer](/automatiseringen/acties/gasten-en-berichten#klant-bijwerken) | Changes the status of a customer or adds a note |
| Guests and messages | [Check in, check out or cancel](/automatiseringen/acties/gasten-en-berichten#inchecken-uitchecken-of-annuleren) | Puts a reservation into its next status |
| Invoices and payments | [Send payment reminder](/automatiseringen/acties/facturen-en-betalingen#betalingsherinnering-versturen) | Sends the payment reminder of an invoice to the customer |
| Invoices and payments | [Sync bank transactions](/automatiseringen/acties/facturen-en-betalingen#banktransacties-synchroniseren) | Fetches new bank transactions before the flow continues |
| Invoices and payments | [Disable automated reminders for customer](/automatiseringen/acties/facturen-en-betalingen#automatische-herinneringen-uitschakelen-voor-klant) | Skips all of a customer's invoices in automated reminders |
| Invoices and payments | [Disable automated reminders for invoice](/automatiseringen/acties/facturen-en-betalingen#automatische-herinneringen-uitschakelen-voor-factuur) | Takes one invoice out of automated reminder flows |
| Invoices and payments | [Send invoice](/automatiseringen/acties/facturen-en-betalingen#factuur-versturen) | Sends an invoice to the customer |
| Invoices and payments | [Book invoice](/automatiseringen/acties/facturen-en-betalingen#factuur-boeken) | Books a draft invoice |
| Invoices and payments | [Print invoice](/automatiseringen/acties/facturen-en-betalingen#factuur-afdrukken) | Prints an invoice or shows it on a tablet |
| Invoices and payments | [Create payment link](/automatiseringen/acties/facturen-en-betalingen#betaallink-aanmaken) | Creates an online payment link for what is still outstanding |
| Invoices and payments | [Request SEPA mandate](/automatiseringen/acties/facturen-en-betalingen#sepa-mandaat-aanvragen) | Asks a customer to sign a mandate, or sends a reminder |
| Invoices and payments | [Collect by direct debit](/automatiseringen/acties/facturen-en-betalingen#innen-via-domiciliëring) | Collects what is outstanding with the customer's active mandate |
| Invoices and payments | [Invoice consumption](/automatiseringen/acties/facturen-en-betalingen#verbruik-factureren) | Invoices a customer's outstanding meter consumption |
| Invoices and payments | [Draft extension invoice](/automatiseringen/acties/facturen-en-betalingen#conceptfactuur-voor-verlenging) | Creates a draft invoice that extends an occupation |
| Access and devices | [Create access method](/automatiseringen/acties/toegang-en-toestellen#toegangsmiddel-aanmaken) | Gives a customer access via QR code, licence plate, PIN code or NFC |
| Access and devices | [Update access](/automatiseringen/acties/toegang-en-toestellen#toegang-bijwerken) | Blocks, unblocks or extends access methods |
| Access and devices | [Send or print QR code](/automatiseringen/acties/toegang-en-toestellen#qr-code-versturen-of-afdrukken) | Sends a QR access code to the customer or prints it |
| Access and devices | [Open or close barrier](/automatiseringen/acties/toegang-en-toestellen#slagboom-openen-of-sluiten) | Opens or closes a barrier or gate |
| Access and devices | [Switch power](/automatiseringen/acties/toegang-en-toestellen#stroom-schakelen) | Turns the power of a smart meter on or off |
| Access and devices | [Update NFC tags](/automatiseringen/acties/toegang-en-toestellen#nfc-tags-bijwerken) | Blocks, unblocks or tops up a customer's NFC tags |
| Access and devices | [Control tablet or kiosk](/automatiseringen/acties/toegang-en-toestellen#tablet-of-kiosk-bedienen) | Wakes a tablet or kiosk, puts it to sleep or reloads it |
| Access and devices | [Set slideshow](/automatiseringen/acties/toegang-en-toestellen#diavoorstelling-instellen) | Puts photos on tablets and kiosks, from a list or an earlier request |
| Integrations | [Send webhook](/automatiseringen/acties/integraties#webhook-versturen) | Delivers a message of your own to one of your webhook endpoints |
| Integrations | [API request](/automatiseringen/acties/integraties#api-verzoek) | Calls the Tillor API or another website |

In all text fields you can use [variables](/automatiseringen/variabelen), such as `{invoice.displayId}`. At the top right of each field is a **Variable** button to insert one. Fields that ask for a customer, invoice or other record expect the internal id of that record, such as `{invoice.id}`. An invoice number or name therefore does not work.

## Exits of an action [#uitgangen-van-een-actie]

Under a step there are one or more exits. You connect each exit to a next step. If you leave an exit unconnected, the run ends there.

| Exit | On which actions | When |
|---|---|---|
| **Next** | Most actions | The step succeeded |
| **Done** and **Skipped** | Actions that sometimes have nothing to do | **Done** if the step did its work. **Skipped** if there was nothing to do, for example because the invoice was already booked. That is not an error |
| **Found** and **Not found** | **Find task** | Whether the task exists |
| **Found** and **Not found** | **Find document** | Whether the customer has such a document |
| **Succeeded** and **Failed** | **Send webhook** and **API request** | Whether the other side accepted the message |

**Done** and **Skipped** are on **Message a guest**, **Check in, check out or cancel**, **Book invoice**, **Create payment link**, **Request SEPA mandate**, **Collect by direct debit** and **Invoice consumption**. For each of them, it says under the action when a step is skipped.

### Continue when this step fails [#doorgaan-als-deze-stap-mislukt]

If an action goes wrong, the run normally stops with the status **Failed**. If you want to decide yourself what happens then, turn on **Continue when this step fails** at the bottom of the step's settings. That is possible for every action except **Send webhook** and **API request**, which already have an exit of their own, **Failed**.

The step then gets an extra exit **Error**. If the action fails, the flow continues via **Error** instead of stopping. Later steps can use these variables:

| Variable | Content |
|---|---|
| `{error.message}` | The error message. It may be in English |
| `{error.step}` | The name of the step that failed, as you filled it in under **Step name** |

A few things to know:

- If the action succeeded or was skipped, nothing changes and **Error** is not used
- If you leave **Error** unconnected, the run ends there without further steps. The run then gets the status **Completed**, but the step itself shows its error message on the **Runs** tab
- A second failed step in the same flow replaces `{error.message}` and `{error.step}` of the first

An example: let **Message a guest** continue if it fails and create a task via **Error** with `{error.message}` in the description. That way a colleague picks up the conversation with the guest themselves.

## When a step fails [#als-een-stap-mislukt]

There are three ways a failure can go.

- **A Failed exit.** This happens with **Send webhook** and **API request** if the other side returns an error. The flow continues via the **Failed** exit. Connect it to a follow-up, such as a task for a colleague. If you leave the exit unconnected, the run simply ends there
- **An Error exit.** If you turn on **Continue when this step fails** on another action, the step gets an **Error** exit and you can use the reason with `{error.message}`. See [Continue when this step fails](#doorgaan-als-deze-stap-mislukt)
- **The step stops the run.** If a value is missing after the variables have been filled in, an invoice cannot be sent, an endpoint no longer exists or the JSON is invalid, the run gets the status **Failed**. The steps after it are not executed and Tillor does not retry the step. This only happens if you have not turned on **Continue when this step fails**

The error message is on the step on the **Runs** tab. Those messages may be in English.

<Callout type="idea" title="Do not miss failures">
Want to make sure a failure never goes unnoticed? Connect the **Failed** exit of an **API request** or **Send webhook**, or the **Error** exit of another action, to a [Create task](/automatiseringen/acties/taken#taak-aanmaken) step. That way a colleague can pick it up.
</Callout>

## Groups [#groepen]

<Cards>
  <Card title="Tasks" href="/automatiseringen/acties/taken" description="Create, find and update tasks" />
  <Card title="Guests and messages" href="/automatiseringen/acties/gasten-en-berichten" description="Messages, comments, inbox and reservations" />
  <Card title="Invoices and payments" href="/automatiseringen/acties/facturen-en-betalingen" description="Reminders, invoices and payments" />
  <Card title="Access and devices" href="/automatiseringen/acties/toegang-en-toestellen" description="Access, power, NFC and tablets" />
  <Card title="Integrations" href="/automatiseringen/acties/integraties" description="Webhooks and API requests" />
</Cards>


# Integrations (/en-GB/automatiseringen/acties/integraties)

These steps are in the **Integrations** group. A failed delivery continues via **Failed**. For other actions, read [When a step fails](/automatiseringen/acties#als-een-stap-mislukt).

## Send webhook [#webhook-versturen]

Delivers a message of your own to one of your organisation's webhook endpoints. That is useful for informing another system, for example your till system or your website.

| Field | What you enter |
|---|---|
| **Endpoint** | Choose one of your webhook endpoints. You recognise them by their address. Required |
| **Event name** | The name sent along in the message so the recipient can recognise it, for example `automation.invoice_unpaid`. Required |
| **Payload** | The content of the message, as JSON. Variables are filled in before the message is sent. Required |

You create and manage endpoints via the profile menu under **Developers**. The endpoint must exist and be enabled. If it is not, the step fails and the run stops.

The message is signed with the endpoint's own key, exactly like the other webhooks the endpoint receives. Tillor tries again a few times if your server does not answer properly. The endpoint does not have to follow the name of your event: the message arrives either way.

The step has two outputs:

| Output | When |
|---|---|
| **Succeeded** | Your server answered with a successful status |
| **Failed** | The delivery failed after all attempts. The message is then retried in the background, just like an ordinary webhook |

The template **Push reservations to another system** uses **Failed** to create a task so that someone picks it up.

A payload looks like this, for example:

```json
{
  "reservation": "{reservation.displayId}",
  "checkIn": "{reservation.checkIn}",
  "adults": {reservation.numberOfAdults},
  "customer": {
    "firstName": "{reservation.customer.firstName}",
    "email": "{reservation.customer.email}"
  }
}
```

Put text between quotation marks and numbers without. Dates are passed in JSON as an international date and time, such as `2026-10-05T08:00:00.000Z`. Read [Variables and templates](/automatiseringen/variabelen#hoe-waarden-worden-ingevuld) for the details. The technical side, such as the structure of the message, is at [Developers > Automations](/ontwikkelaars/automatiseringen).

## API request [#api-verzoek]

Calls the Tillor API of your own organisation, or another address on the internet. With this you can do almost anything Tillor can do, and look up data to then do something with it.

Under **Send to** you choose between **Tillor API** and **Custom URL**. Under **Method** you choose **GET** (retrieve), **POST** (create), **PUT** or **PATCH** (change) or **DELETE** (remove).

### Tillor API [#tillor-api]

| Field | What you enter |
|---|---|
| **Path** | The part of the address after your organisation's API, for example `/tasks` or `/tasks/{task.id}`. It must start with `/`. Required |
| **Body** | The data you send along, as JSON. Leave empty if you send nothing |

At the top of the field is **Pick an API endpoint**. Click it and search the list, for example *tasks*. When you pick an endpoint, Tillor fills in the method and the path. If the **Body** is still empty, you also get an example of what the endpoint expects. Replace the names between braces in the path with variables from earlier steps. If there are query parameters, you see that under the field.

The call is made as the **Workflow** user and can never reach outside your own organisation. An automation cannot manage automations, so calls that touch automations or their runs are refused.

### Custom URL [#eigen-url]

| Field | What you enter |
|---|---|
| **URL** | The address. It must start with `https://`. Required |
| **Headers** | Extra data for the recipient, for example a key. Click **Add header** and fill in the **Name** and the **Value** |
| **Body** | The data you send along, as JSON. Leave empty if you send nothing |

These rules apply:

- Addresses without `https://` are refused
- Private and internal addresses are refused, even if an ordinary name points to them
- Redirects are not followed. If the server answers with a redirect, that counts as **Failed**
- Headers are stored encrypted. So you can put a key or token in them
- With **GET** and **DELETE** no body is sent

### Outputs and response [#uitgangen-en-antwoord]

The request has two outputs: **Succeeded** (the server answered with a successful status) and **Failed** (the server answered with an error status). If Tillor does not reach the server at all, for example because of a timeout after 15 seconds or a refused address, the run stops with the status **Failed**.

There are three variables for later steps:

| Variable | Content |
|---|---|
| `{response.status}` | The status code, for example 200 |
| `{response.body}` | The response as text, shortened to the first 4000 characters |
| `{response.data}` | The response as data, so you can pick fields from it with `{response.data.items.0.id}` |

How to use that is at [Using an API response](/automatiseringen/variabelen#een-api-antwoord-gebruiken). A complete example with a search request is at [Holiday caravan check](/automatiseringen/voorbeeld-nalopen).


# Tasks (/en-GB/automatiseringen/acties/taken)

With these steps an automation creates and updates tasks, so that a colleague picks something up. They are in the **Tasks** group. For how the outputs work, read [Outputs of an action](/automatiseringen/acties#uitgangen-van-een-actie).

## How does this fit together? [#hoe-hangt-dit-samen]

A task created by an automation is an ordinary task: you find it on the tasks page, in the views it fits and on the customer or record it is linked to.

```mermaid
flowchart LR
  A["Create task step"] --> T["Task on the tasks page<br/>in the name of Workflow"]
  T --> V["Views show it<br/>if it fits or is in the list"]
  T --> C["A colleague picks it up"]
  C -- "Status or assignment changes" --> E["Another automation can start on that"]
  D["Ask for a decision step"] --> T2["Task with choice buttons"]
  T2 -- "A colleague chooses a button" --> F["The automation continues via that option"]
```

More about what colleagues see and do is in [Tasks](/taken) and [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen).

## Create task [#taak-aanmaken]

Creates a task in the task system. The task is created in the name of **Workflow**.

<DocScreenshot src="/screenshots/taken/automation-task-create-step.png" alt="Automation with the Create task step selected and its settings on the right" />


| Field | What you enter |
|---|---|
| **Title** | The name of the task. Required |
| **Description** | An explanation for the task |
| **Assign to** | Choose one or more colleagues. Click a name to switch it on or off |
| **Assign to groups** | Choose one or more [groups](/gebruikers/groepen). The task then applies to everyone who is in the group at that moment |
| **Labels** | Choose one or more [labels](/taken/labels) |
| **Also assign whoever caused the event** | Also assigns the task to the colleague who caused the event, for example whoever ended the occupancy. If the system caused the event, nobody is added |
| **Priority** | **Low**, **Medium**, **High** or **Urgent**. **Medium** by default |
| **Add to board** | Choose a board the task is placed on, or leave it empty |
| **Column** | Choose a column of the board above. The list shows the columns as *[board] · [column]* |
| **Subtasks** | One subtask per line, or exactly one variable containing a list, such as `{result}` from [Run code](/automatiseringen/logica#code-uitvoeren) |
| **Due after** | How many minutes, hours, days or weeks after the step runs the deadline falls. At 0 the task gets no deadline. 1 day by default |
| **Link to records** | Links the task to the records below and to their customer, terrain, invoice, reservation or meter. On by default |
| **Link to** | Appears when **Link to records** is on. Choose which records the task appears on. Everything the step knows is ticked beforehand: the records of the trigger and whatever an earlier lookup step found |
| **Only the flow can finish it** | Colleagues cannot complete or delete the task. Add a **Delete task** or **Set task status** step later in the flow to finish it |

Keep in mind:

- If you choose nobody under **Assign to** or **Assign to groups** and leave **Also assign whoever caused the event** off, the task has no assignee. **Workflow** is never assigned itself
- Subtasks get the title you enter, no assignee and no deadline. Empty lines are skipped. You may use variables in the lines
- **Link to** concerns customers, terrains, invoices, reservations and meters. For an occupancy that ends, the task is therefore linked to the terrain, the customer and the reservation by default. If you remove a record from the list, the task stays away from it. Records that join the flow later are not added automatically by Tillor once you have edited the list yourself. Choose everything again and the step follows all available records once more
- If a task is only on a personal board, only the people involved see it. See [Private tasks](/taken/prive-taken)

For later steps the action provides `{createdTask.id}` and `{createdTask.name}`. With those you can, for example, set the status afterwards.

If you do not want a second task when an open task already exists for the same terrain or customer, first add a [Find task](#taak-zoeken) step and create the task only via **Not found**. The [Holiday caravan check example](/automatiseringen/voorbeeld-nalopen) does that.

If you switch on **Only the flow can finish it**, the task shows **Finished by its automation**. Colleagues cannot complete or delete it.

## Delete task [#taak-verwijderen]

Deletes a task, for example the task this flow created once it is no longer needed.

| Field | What you enter |
|---|---|
| **Task** | The id of the task. `{createdTask.id}` by default. Required |

A task that is already gone is skipped. The flow then simply continues.

## Set task status [#taakstatus-zetten]

Changes the status of an existing task, for example to complete it.

| Field | What you enter |
|---|---|
| **Task** | The id of the task. `{task.id}` by default. Required |
| **Status** | **Pending**, **In Progress**, **Waiting for reply** or **Completed**. **Completed** by default |

`{task.id}` works when the automation starts on a task event, such as `task:created`. After a **Create task** step, use `{createdTask.id}`. The action provides `{updatedTask.id}` and `{updatedTask.status}`.

## Find task [#taak-zoeken]

Looks for an existing task by title. The step has two outputs: **Found** and **Not found**. That way you can update a task if it already exists, and otherwise create a new one.

| Field | What you enter |
|---|---|
| **Title** | The title the task must have exactly, for example `Nalopen {occupation.terrain.name}`. Variables are filled in first. Required |
| **Linked to the records of the event** | Only tasks linked to at least one of the same records, such as the terrain or the customer. On by default |
| **Only tasks that are not completed** | Skips completed tasks. On by default |
| **Skip subtasks** | Looks only for main tasks. On by default |

If several tasks match, the step takes the newest. If **Linked to the records of the event** is on but the event has no customer, terrain, invoice, reservation or meter, the flow goes via **Not found**.

Via **Found**, later steps can use `{foundTask.id}`, `{foundTask.name}`, `{foundTask.priority}` and `{foundTask.status}`.

## Set task priority [#taakprioriteit-zetten]

Changes the priority of an existing task.

| Field | What you enter |
|---|---|
| **Task** | The id of the task. `{foundTask.id}` by default. Required |
| **Change** | **One step higher** (default), **One step lower** or **To a fixed priority** |
| **Priority** | Only with **To a fixed priority**: **Low**, **Medium**, **High** or **Urgent** |
| **Raise up to** | Only with **One step higher**: the highest priority the step may give. **High** by default. A task that is already that high or higher stays as it is |

The order is **Low**, **Medium**, **High**, **Urgent**. One step lower stops at **Low**. If nothing changes, the step simply succeeds without changing the task. The action provides `{updatedTask.id}` and `{updatedTask.priority}`.

## Update task [#taak-bijwerken]

Changes an existing task. Fields you leave empty stay as they are.

| Field | What you enter |
|---|---|
| **Task** | The id of the task. `{foundTask.id}` by default. Required |
| **New title** | The new name of the task. Empty leaves the title as it is |
| **Assignees** | Choose one or more colleagues |
| **Groups** | Choose one or more [groups](/gebruikers/groepen) |
| **Also assign whoever caused the event** | Also adds the colleague who caused the event. If the system caused the event, nobody is added |
| **Assignees** | **Add to the current ones** (default) or **Replace the current ones** |
| **Add labels** | Choose one or more [labels](/taken/labels). They are added, existing labels stay |
| **Due after** | Sets the deadline to this many minutes, hours, days or weeks after the step runs. At 0 the deadline stays as it is |

Keep in mind:

- If you choose **Replace the current ones** and specify nobody, the task has no assignee afterwards
- If the task no longer exists, the step fails
- The action provides `{updatedTask.id}`


# Access and devices (/en-GB/automatiseringen/acties/toegang-en-toestellen)

These actions affect the park itself: who gets in, which meters have power and what tablets do. See [Access control](/toegangscontrole) for the background on access methods. For how the outputs work, read [Outputs of an action](/automatiseringen/acties#uitgangen-van-een-actie).

## Create access method [#toegangsmiddel-aanmaken]

Gives a customer access via a QR code, licence plate, PIN code or NFC.

| Field | What you enter |
|---|---|
| **Customer** | The id of the customer, for example `{reservation.customerId}`. Required |
| **Type** | **QR code** (default), **License plate**, **PIN code** or **NFC** |
| **Value** | The licence plate or the NFC number. Leave empty for a QR code or PIN code, because Tillor creates those itself |
| **Valid from** | A date variable, for example `{reservation.checkIn}`. Empty means no limit |
| **Valid until** | A date variable, for example `{reservation.checkOut}`. Empty means no limit |

For **License plate** and **NFC**, **Value** is required. The action provides `{createdAccessMethod.id}` and `{createdAccessMethod.value}`. The value is the code of the QR code or the PIN code. With the id you can then send the code via **Send or print QR code**.

## Update access [#toegang-bijwerken]

Blocks, unblocks or extends an access method, or all access methods of a customer.

| Field | What you enter |
|---|---|
| **Which** | **One access method** (default) or **All of a customer** |
| **Access method** | Only with **One access method**: the id, for example `{createdAccessMethod.id}`. Required |
| **Customer** | Only with **All of a customer**: the id of the customer, for example `{occupation.customerId}`. Required |
| **Status** | **Leave as it is** (default), **Active**, **Soft blocked**, **Blocked** or **Inactive** |
| **Valid until** | A date variable. Empty keeps the current end date |

Keep in mind:

- If you leave **Status** on **Leave as it is** and **Valid until** empty, the step does nothing
- With **All of a customer**, access methods set to **Do not extend automatically** keep their end date, just as happens when a customer pays an invoice. Their status does change. With **One access method** the step does change the end date, even if that access method is set to **Do not extend automatically**

## Send or print QR code [#qr-code-versturen-of-afdrukken]

Sends a QR access code to the customer, prints it, or both.

| Field | What you enter |
|---|---|
| **Access method** | The id of the access method. `{createdAccessMethod.id}` by default. Required |
| **Send by e-mail** | On by default |
| **Send by text message** | Off by default |
| **Send by WhatsApp** | Off by default |
| **Print** | **Do not print** (default), **Label printer** or **Receipt printer** |

If you switch off all three channels and choose **Do not print**, the step does nothing.

## Open or close barrier [#slagboom-openen-of-sluiten]

Opens or closes a barrier or gate.

| Field | What you enter |
|---|---|
| **Access point** | Choose one of your access points. Required |
| **Action** | **Open** (default) or **Close** |

## Switch power [#stroom-schakelen]

Switches the power of a smart meter on or off. For example, to switch the power off when an occupancy ends.

| Field | What you enter |
|---|---|
| **Which meters** | **Every switchable meter of a terrain** (default) or **One meter** |
| **Terrain** | Only with **Every switchable meter of a terrain**: the id of the terrain. `{occupation.terrainId}` by default. Required |
| **Meter** | Only with **One meter**: choose the meter. Required |
| **Power** | **On** or **Off**. **Off** by default |

Keep in mind:

- With **Every switchable meter of a terrain** the step only switches the meters that can switch. If the terrain has none, nothing happens
- If switching a meter fails, the step fails. With **One meter** that also happens if the meter cannot switch. Meters that were already switched before stay switched

## Update NFC tags [#nfc-tags-bijwerken]

Updates all [NFC tags](/nfc/nfc-tags) of a customer.

| Field | What you enter |
|---|---|
| **Customer** | The id of the customer, for example `{occupation.customerId}`. The action applies to every NFC tag of this customer. Required |
| **Action** | **Block** (default), **Unblock**, **Top up** or **Send low balance message** |
| **Amount** | Only with **Top up**: the amount in euros, per tag. Must be greater than 0. Required |

If the customer has two tags and you enter 20, each tag gets 20 euros added. Without tags the step does nothing. If the amount is not a number above 0, the step fails.

## Control tablet or kiosk [#tablet-of-kiosk-bedienen]

Sends a command to a [tablet or kiosk](/mobiele-app/tablets-en-kiosken).

| Field | What you enter |
|---|---|
| **Device** | Choose the device. Required |
| **Command** | **Wake** (default), **Sleep**, **Reload**, **Identify** or **Play test sound** |

## Set slideshow [#diavoorstelling-instellen]

Sets the slideshow on every tablet and kiosk, or on one device. The rest of the device settings stay as they are. If the same slideshow is already on a device, that device is skipped.

An hourly trigger, then an [API request](/automatiseringen/acties/integraties#api-verzoek) to an activities feed, and then this step: that is how you replace a separate synchronisation. Connect the step to the **Succeeded** output of the request.

| Field | What you enter |
|---|---|
| **Devices** | **Every tablet and kiosk** (default) or **One device** |
| **Device** | Only with **One device**. Required |
| **Mode** | **Screensaver** (default, after a period without touch) or **Background** |
| **Seconds per photo** | How long one photo stays. 10 by default. From 3 to 600 |
| **Idle before it starts** | Only with **Screensaver**: seconds without touch. 15 by default |
| **Fit** | **Fill** or **Fit inside** |
| **Photos** | **From a previous request** (default) or **Addresses** |
| **Image addresses** | Only with **Addresses**: one https address per line. Required |
| **List** | Path of the JSON list, without braces. After an API request that is `response.data`. Required |
| **Image field** | Name of the field with the https address, for example `signage_image`. Required |
| **Id field** | Keeps the same id for the same photo, so an unchanged list does not send a new message to the device |
| **Status field** and **Status** | Only rows where that field has this value, for example `CONFIRMED` |
| **Skip when set** | Rows where this field has a value are dropped, for example `deleted_at` |
| **Date field** and **End date field** | A row stays until that moment has passed. If the end date is empty, the date counts |
| **Sort field** | Sorts the list ascending, for example by `date` |
| **Maximum photos** | 5 by default, at most 20 |

An address that does not start with `https://` is not counted. If the list is not a JSON array, the step fails and the current slideshow stays in place.


# Overview (/en-GB/automatiseringen)

With automations you let Tillor do something without a colleague having to remember it. You set a rule: *when this happens, do that*. A few examples:

- An occupancy on a static caravan ends, so Tillor creates a check task with subtasks and assigns it to the colleague who stopped the occupancy
- An invoice is overdue, so Tillor sends a payment reminder and, a week later, creates a task to call the customer if the invoice is still open
- A new reservation comes in, so Tillor sends the details to your own system
- Every Monday at 08:00 Tillor creates a task for the weekly check
- A new reservation comes in, so Tillor creates a QR code for the guest and sends it by e-mail

You build an automation yourself on a canvas, without code. You choose a starting moment, add steps and connect them with lines.

## In plain words [#in-gewone-woorden]

An automation has three kinds of building blocks. You only need the technical details when you need them.

- **The starting moment (trigger)** is the "when". Something happens in Tillor, such as an occupancy ending, or it is a certain hour or a certain date. See [Triggers](/automatiseringen/triggers)
- **The logic** is the "if". Here the flow looks at the data and picks a route, or waits until something happens. An example: *is the invoice still unpaid after a week?* See [Conditions, switches and delays](/automatiseringen/logica)
- **The actions** are the "then do". Create a task, send a message, book an invoice. See [Actions](/automatiseringen/acties)

In addition, **variables** are the data of the moment itself, such as the name of the terrain or the customer. You put them between braces in a text, and Tillor fills in the real value. See [Variables and templates](/automatiseringen/variabelen).

## Who can use it [#wie-kan-het-gebruiken]

<Callout type="warn" title="Administrators only">
Automations work with full permissions in your organisation. Viewing requires the permission **View automations**, building and changing requires **Manage automations**. Administrators with **All permissions** can do both. See [Who can use automations?](/automatiseringen/veelgestelde-vragen#wie-kan-automatiseringen-gebruiken).
</Callout>

You find the page in the side menu under <UIPath>Admin > Automations</UIPath>.

## How does this fit together? [#hoe-hangt-dit-samen]

Every automation consists of steps that you connect into a flow. An automation works together with tasks: it creates tasks, waits for a colleague to choose a button, or starts as soon as a task changes. See [Tasks](/taken#hoe-hangt-dit-samen). Each time an automation starts, we call that a run. A run begins at the starting moment and follows the lines downwards.

| Part | What it does |
|---|---|
| **When this happens** (trigger) | The starting moment. An event in Tillor, a webhook, a chosen task action, an overdue invoice, a date such as a guest's arrival, a fixed hour or a schedule of your own. A flow can have several triggers. Each trigger starts a run of its own |
| **Only when** | A filter on the trigger. The automation only starts if the data matches, for example only for static caravans |
| **If / else** | Splits the flow into **Yes** and **No** based on one or more conditions |
| **Switch** | Splits the flow into several branches, depending on the value of a field |
| **Delay** and other wait steps | Make the flow wait for a time, a date, the opening hours, a condition, an event or a colleague's decision |
| **Open now?**, **Look up a record**, **For each** | Check whether you are open, fetch a record or run the steps after it for each item in a list |
| **Actions** | Really do something: tasks, messages to guests and colleagues, invoices, payments and mandates, access, meters and devices, webhooks and API requests |

Steps with several outputs, such as **Yes** and **No**, **Done** and **Skipped** or **Succeeded** and **Failed**, let you choose a different continuation per outcome. For every action you can also switch on an **Error** output, so the flow continues if the step fails.

```mermaid
flowchart TD
  A["When this happens<br/>Invoice is overdue"] --> B["Send payment reminder"]
  B --> C["Delay<br/>7 days"]
  C --> D{"If / else<br/>still unpaid?"}
  D -- Yes --> E["Create task<br/>call customer"]
  D -- No --> F["End"]
```

## Variables [#variabelen]

Text fields in a step accept variables between braces, such as `{occupation.terrain.name}`. Tillor fills in the name of the terrain that belongs to the event. That way you make messages and tasks that differ per case. Read more at [Variables and templates](/automatiseringen/variabelen).

## Getting started quickly [#snel-aan-de-slag]

1. Go to **Admin > Automations** and click **New automation**
2. Choose a template or **Start from scratch**
3. Set the trigger and the steps and click **Save**
4. Try the flow on the **Test run** tab. Nothing is really sent or created then
5. Switch on **Active** when you are happy

The new automation is paused until you switch it on yourself. A step-by-step explanation is at [Getting started](/automatiseringen/aan-de-slag).

<Callout type="info" title="Good to know">
- A new automation is paused until you switch it on yourself
- An automation has at most 100 steps. Notes and frames on the canvas count separately, at most 50
- A **Switch** has at most 8 branches, and **Ask for a decision** at most 8 options
- Schedules and dates are checked every minute. An event starts immediately
- Changes can take half a minute before they apply everywhere
- A failed run is e-mailed to whoever made the automation, at most once an hour
- The **Runs** tab shows the last 20 runs
- A flow cannot start itself or another flow through what it creates itself
</Callout>

<Callout type="info" title="Automations really do something">
An automation that is switched on sends real reminders and creates real tasks. Use the **Test run** tab and check the first runs on the **Runs** tab before you are sure everything is right.
</Callout>

## Parts [#onderdelen]

<Cards>
  <Card
    title="Getting started"
    href="/automatiseringen/aan-de-slag"
    description="The overview, the templates and the editor, and how to save and switch on an automation"
  />
  <Card
    title="Triggers"
    href="/automatiseringen/triggers"
    description="Events, dates, overdue invoices and schedules, plus filters and starting once"
  />
  <Card
    title="Conditions, switches and delays"
    href="/automatiseringen/logica"
    description="Splitting and pausing the flow, looking up records, looping through lists and asking for a decision"
  />
  <Card
    title="Actions"
    href="/automatiseringen/acties"
    description="Everything an automation can do, with all fields"
  />
  <Card
    title="Variables and templates"
    href="/automatiseringen/variabelen"
    description="Using data of the event in your texts"
  />
  <Card
    title="Who runs an automation?"
    href="/automatiseringen/workflow-gebruiker"
    description="Why tasks and comments from an automation are in the name of a fixed system user"
  />
  <Card
    title="Testing and runs"
    href="/automatiseringen/testen-en-uitvoeringen"
    description="Doing a test run and looking back at real runs"
  />
  <Card
    title="Problems and switching on"
    href="/automatiseringen/problemen"
    description="Why an automation cannot be switched on and what the messages mean"
  />
  <Card
    title="Example: holiday caravan check"
    href="/automatiseringen/voorbeeld-nalopen"
    description="Building a complete flow step by step"
  />
  <Card
    title="Frequently asked questions"
    href="/automatiseringen/veelgestelde-vragen"
    description="Limits, an explanation of pausing and what to do when nothing happens"
  />
  <Card
    title="For developers"
    href="/ontwikkelaars/automatiseringen"
    description="The API request, the webhook envelope, signing and management via the API"
  />
</Cards>

<Cards>
  <Card title="Practical examples" href="/praktijk" description="Worked examples from practice" />
</Cards>

## Terms [#begrippen]

- **Automation**: a rule of "when this happens, do that", built as a flow
- **Flow**: the canvas of one automation, with steps and lines
- **Trigger**: the starting moment of a flow
- **Run**: one time an automation starts and goes through the flow
- **Action**: a step that really does something, such as creating a task
- **Variable**: a piece of data of the moment, between braces in a text
- **Test run**: a trial in which nothing is really sent or created
- **Workflow**: the user in whose name an automation works

More terms are in the [glossary](/begrippen).


# Conditions, switches and delays (/en-GB/automatiseringen/logica)

With the steps in the **Logic** group you decide which way a flow goes and when: the "if" and the "wait a moment". An example: *if the invoice is still open after a week, create a task*. They steer the actions that follow. Only [Ask for a decision](#vraag-om-een-beslissing) creates something itself, a task.

| Step | What it does | Outputs |
|---|---|---|
| [If / else](#als--anders) | Splits on conditions | **Yes**, **No** |
| [Switch](#schakel) | Picks a branch based on the value of a field | One per branch and **Default** |
| [Delay](#vertraging) | Waits a fixed time or until a date | **Next** |
| [Open now?](#nu-open) | Checks whether you are open now | **Open**, **Closed** |
| [Wait until open](#wachten-tot-open) | Waits until the next opening time | **Next** |
| [Wait until closed](#wachten-tot-gesloten) | Waits until the next closing time | **Next** |
| [At most once per period](#hoogstens-één-keer-per-periode) | Stops repeats | **Continue**, **Already ran** |
| [Look up a record](#record-opzoeken) | Fetches a record by its id | **Found**, **Not found** |
| [For each](#voor-elk) | Runs the steps after it for each item in a list | **For each**, **Done** |
| [Wait until](#wachten-tot) | Waits until conditions are met | **Met**, **Timed out** |
| [Wait for an event](#wachten-op-een-gebeurtenis) | Waits until something happens in Tillor | **Received**, **Timed out**, sometimes **Deleted** |
| [Ask for a decision](#vraag-om-een-beslissing) | Lets a colleague choose between your options | One per option and **Timed out** |

## If / else [#als--anders]

Splits the flow into two paths based on the data. It is the same principle as the filter under **Only when** of the trigger, but in the middle of the flow.

The step has two outputs: **Yes** (the conditions are met) and **No** (they are not).

1. Add an **If / else** step
2. Under **Conditions**, click **Add condition**
3. Pick the field with the **Variable** button, or type the path yourself, for example `invoice.paymentStatus`
4. Pick the comparison (**is**, **is not**, **contains**, **is greater than**, **is less than**, **is one of**, **is empty** or **is not empty**) and enter the value
5. Connect the **Yes** output and optionally **No** to a next step

An **If / else** step needs at least one condition. Otherwise Tillor says **Add a condition.** With several conditions you choose between **All must match** and **Any may match**. The comparisons work as described under [Only when](/automatiseringen/triggers#alleen-wanneer).

You do not have to connect both outputs. If an output leads nowhere, the run ends there. A flow that only does something on **Yes** is therefore fine.

You can also use fields from earlier steps. After an [API request](/automatiseringen/acties/integraties#api-verzoek), for example, you can look at `response.status` or `response.data.paymentStatus`.

## Switch [#schakel]

Choose **Switch** when you need more than two paths. The step looks at the value of one field and picks the branch that goes with it.

1. Under **Field**, pick the field you want to look at, for example `occupation.occupationType`
2. Under **Branches**, click **Add branch**. Enter the **Branch** (the name that appears on the output) and **Equals** (the value the field must have)
3. Repeat this for each branch
4. Connect each output to a next step

Each branch gets its own output below the step. There is also always a **Default** output. It is used when no branch fits.

- The field must match the value exactly, including capitals
- If more than one branch fits, the first in the list wins
- A branch without a value under **Equals** does not count
- You can set up to 8 branches, plus **Default**
- If the field is empty or does not exist, the flow goes via **Default**

Values of choice fields use Tillor's notation. An occupancy of the rental caravan type, for example, has the value `RENTAL_CARAVAN`, and a paid invoice has `PAID`.

<Callout type="info">
The list under **Field** shows the fields of the event and of earlier steps. Fields from the response of an API request only appear in the list once Tillor knows a sample of that response. See [Using an API response](/automatiseringen/variabelen#een-api-antwoord-gebruiken).
</Callout>

## Delay [#vertraging]

With **Delay** you make the flow wait before it carries on. You use it for things like *look again a week later*.

Under **Wait**, choose one of two ways.

### For a fixed time [#een-vaste-tijd]

Choose **For a fixed time** and enter a number and a unit under **Duration**: **seconds**, **minutes**, **hours**, **days** or **weeks**. Seconds are not exact. The flow may carry on a few seconds later.

A delay of 0 does nothing, which is why Tillor says **A delay of 0 does nothing.**

### Until a date [#tot-een-datum]

Choose **Until a date** when the wait depends on a date from the data, such as the due date of an invoice or the end date of a reservation.

| Field | What you enter |
|---|---|
| **Date** | A field that holds a date, for example `invoice.dueDate`. The list only shows fields that are dates |
| **Relative to that date** | **Before** or **After** |
| **Offset** | How much time before or after that date, in minutes, hours, days or weeks. At 0 the flow carries on exactly on that date |

Examples:

- **Date** `invoice.dueDate`, **After**, **Offset** 1 day: the flow carries on a day after the due date
- **Date** `reservation.checkIn`, **Before**, **Offset** 2 days: the flow carries on two days before arrival

If that moment is already in the past, or the date is empty, the flow carries on straight away.

### What happens while it waits [#wat-er-tijdens-het-wachten-gebeurt]

- The run gets the status **Waiting**. On the **Runs** tab you can see when it carries on (**Continues …**). Long waits, such as weeks, are no problem
- After the delay Tillor reads the data again, so the steps after it see the current situation. See below
- If you pause the automation while it waits, the run stops as soon as the wait is over. It does not carry on and gets the status **Canceled**. If you switch the automation on before the wait is over, the run simply carries on
- If you delete the automation, the waiting runs stop
- If you change the flow while a run is waiting, that run finishes with the flow as it was when it started

### Data is read again [#gegevens-worden-opnieuw-gelezen]

A run remembers the data from the moment of the event, but reads the records that belong to it again before it carries on. These are the record of the event (for example the invoice) and the records it refers to (for example the customer).

An example: an automation sends a reminder for an invoice, waits 7 days and then checks with **If / else** whether `invoice.paymentStatus` is not `PAID`. If the invoice was paid during that week, the condition sees the paid invoice and the flow goes via **No**.

There are two exceptions:

- If the record no longer exists, for example because an occupancy was deleted, the run keeps the copy from the moment of the event
- Data that an earlier step produced, such as the response of an API request, is not fetched again. If you want such data refreshed after a delay, make a new API request

<Callout type="info" title="Nothing is read again in a test">
A [test run](/automatiseringen/testen-en-uitvoeringen) skips delays and works with the sample data you enter yourself. What happens after a real delay only shows in a real run.
</Callout>

## Open now? [#nu-open]

Checks whether your organisation is open at this moment and splits the flow into **Open** and **Closed**. There is nothing to set up. Tillor uses the hours under **Settings > Opening hours**, with seasonal periods, public holidays and exceptions. See [Organisation settings](/gebruikers/organisaties#openingsuren).

Use it, for example, to send a different text outside opening hours or to create a task. If you would rather wait until you are open again, use [Wait until open](#wachten-tot-open). If you want to wait until you close, use [Wait until closed](#wachten-tot-gesloten).

## Wait until open [#wachten-tot-open]

Pauses the flow until the next opening time and then carries on. Is your organisation already open? Then the flow carries on straight away. There is nothing to set up.

- The opening time comes from **Settings > Opening hours**, in your organisation's time zone
- If there is no opening time at all in the coming month, the flow carries on straight away instead of waiting forever
- While it waits, the run gets the status **Waiting**. What happens then is described under [Delay](#wat-er-tijdens-het-wachten-gebeurt)

## Wait until closed [#wachten-tot-gesloten]

Pauses the flow until the next closing time and then carries on. Is your organisation already closed? Then the flow carries on straight away. There is nothing to set up.

- The closing time comes from **Settings > Opening hours**, in your organisation's time zone
- Blocks that join up, such as 9:00-12:00 and 12:00-17:00, count as one stretch. The flow waits until the end of that stretch
- While it waits, the run gets the status **Waiting**. What happens then is described under [Delay](#wat-er-tijdens-het-wachten-gebeurt)

## At most once per period [#hoogstens-één-keer-per-periode]

Only lets the flow through if it has not passed this step for the same record within the period. That way you do not send a customer the same reminder every day.

| Field | What you enter |
|---|---|
| **Period** | How long earlier runs count, in minutes, hours, days or weeks. 1 day by default |
| **Per** | What you count by. Empty means per record the flow started on, such as the invoice or the reservation. Enter a variable, for example `{customer.id}`, to count per customer or per terrain |

The step has two outputs: **Continue** if the flow has not passed through it within the period, and **Already ran** if it has. Connect **Already ran** to another step, or leave it empty so the run ends there.

Note the following:

- Only runs of the same automation count, and only if they passed this step via **Continue**
- The run that is going now does not count itself
- If the flow starts without a record, for example with **Every day at a time**, enter a variable yourself under **Per**. Without that value every run is new and the step stops nothing

An example: **Period** 7 days and **Per** `{invoice.customerId}` lets through at most one reminder per customer per week, even if that customer has several overdue invoices.

## Look up a record [#record-opzoeken]

Loads a record based on its id, so the steps after it can use its fields. This is handy when the event only passes on an id, such as the message in an inbox conversation.

| Field | What you enter |
|---|---|
| **Record type** | **Customer**, **Reservation**, **Occupation**, **Invoice**, **Payment**, **Terrain**, **Task**, **Document**, **Access method**, **NFC tag**, **Meter**, **Inbox conversation** or **Inbox message**. **Inbox message** by default |
| **Id** | The id of the record, for example `{messageId}`. Required |

The step has two outputs: **Found** and **Not found**. If the record does not exist or the id is empty, the flow goes via **Not found**.

After **Found**, the fields of the record are in variables that start with `found` followed by the type: `{foundCustomer.firstName}`, `{foundInvoice.displayId}`, `{foundReservation.checkIn}`, `{foundTerrain.name}`, `{foundInboxMessage.direction}`. The other types are called `foundOccupation`, `foundPayment`, `foundTask`, `foundAccessMethod`, `foundNfcTag`, `foundMeter` and `foundInboxThread`. The records it refers to are included too, one level deep, such as `{foundReservation.customer.firstName}`. Everything is in the list behind the **Variable** button.

A second lookup of the same type replaces the first. Watch out with **Task**: it uses the same name `foundTask` as [Find task](/automatiseringen/acties/taken#taak-zoeken), and the last of the two wins. The same goes for **Document** and `foundDocument` of [Find document](/automatiseringen/acties/documenten#document-zoeken).

## Map variables [#variabelen-mappen]

Copies values to new variable names, so later steps can use one shape. This is handy when one flow starts via **Incoming webhook** (`{body.…}`) and via **Invoice is overdue** (`{invoice.…}`).

| Field | What you enter |
|---|---|
| **Mappings** | Rows with **Target variable** (e.g. `invoice`) and **Source** (e.g. `{foundInvoice}` or `{body.invoiceId}`) |

The step has one output: **Next**. If the source is exactly one variable between braces, for example `{foundInvoice}`, Tillor copies the whole record (object). Otherwise Tillor fills in the source as text, such as `Invoice {foundInvoice.displayId}` in `meta.label`.

A typical webhook test: **Incoming webhook** → **Look up a record** (Invoice, id `{body.invoiceId}`) → **Map variables** (`invoice` ← `{foundInvoice}`) → the same conditions and approval as with the schedule trigger.

## Run code [#code-uitvoeren]

Runs a piece of TypeScript on the variables of the flow and keeps what it returns as a new variable. For logic that you cannot fit into fields and conditions: which subtasks are needed, calculating an amount or date, reshaping a webhook body.

| Field | What you enter |
|---|---|
| **Code** | TypeScript. You write variables as in texts, with braces: `{customer.firstName}` is read as a value, not filled in as text. End with `return`. Required |
| **Output variable** | The name under which later steps read the result, such as `result` (then `{result}`) or `result.names`. `result` by default |

The step has one output: **Next**. This is how it works:

- The code only sees the variables it mentions. A variable the flow does not have is `null`; a date arrives as text (`2026-07-01T10:00:00.000Z`)
- Formatting and date shifts (`{amount|currency}`, `{date + 1 day}`) do not work here: calculate them in the code
- Return a list, text, number or object. You then read an object per field: `{result.total}`
- The code cannot fetch or send anything: no internet, no database. It only calculates. Calculating for too long (more than 50 ms) is cut off
- If the code throws an error, the run stops with that error and the line number. You see them on the **Runs** tab
- To the right of the code you immediately see what it returns on the sample; it runs along when you test

An example: after departure you want subtasks that depend on the terrain. Add a **Run code** step with:

```ts
const tasks = ["Plaats vegen", "Sanitair"];
if ({occupation.terrain.metadata.gasMeterNumber}) tasks.push("Gasmeterstand noteren");
return tasks;
```

Then fill the **Subtasks** field of **Create task** with only `{result}`: each text in the list becomes a subtask.

## For each [#voor-elk]

Runs the steps after **For each** once for each item in a list, for example for each open invoice of a customer. The flow itself carries on via **Done**.

| Field | What you enter |
|---|---|
| **List** | **Access methods of a customer**, **NFC tags of a customer**, **Open invoices of a customer**, **Booked reservations of a customer**, **Occupations of a customer**, **Documents of a customer** (active only) or **Meters of a terrain**. **Access methods of a customer** by default |
| **Of** | The customer or terrain whose list you want, for example `{customer.id}` or `{occupation.terrainId}`. Required |

The step has two outputs with a meaning of their own:

- **For each** leads to the steps you want to take per item
- **Done** is how the flow itself carries on

This is how it works:

- Each item gets its own run, which goes through the steps after **For each** to the end of that branch. You see them on the **Runs** tab, which only shows the last 20
- The item is in the variable `item`, for example `{item.id}`. Variables of the event and of earlier steps stay available
- The flow does not wait until the items are finished. Immediately after they have started, it carries on via **Done**. So you cannot use the outcome of an item in the steps after **Done**
- At most 100 items are processed, the oldest first. If the list holds more, the rest are not processed
- If the list is empty or the **Of** field is empty, nothing starts and the flow carries on straight away via **Done**
- **Open invoices of a customer** are booked invoices with something still outstanding. **Booked reservations of a customer** are reservations with the status **Booked**

An example: an invoice becomes overdue and you want to make a payment link for each open invoice of that customer. Choose **Open invoices of a customer**, enter `{invoice.customerId}` under **Of** and put a **Create payment link** step after **For each** with `{item.id}` as the invoice.

## Wait until [#wachten-tot]

Checks conditions again and again until they are met, or stops after a while. Use it when you do not know when something will happen but do know what you are waiting for, for example until an invoice is paid.

| Field | What you enter |
|---|---|
| **Until** | One or more conditions, in the same way as with [If / else](#als--anders) |
| **Check every** | How often Tillor looks again, in minutes, hours, days or weeks. At least 5 minutes. 1 hour by default |
| **Stop waiting after** | How long the step waits at most. 7 days by default |

The step has two outputs: **Met** (the conditions are met) and **Timed out** (the wait is over without them being met).

Note the following:

- The first check happens straight away. If the conditions are already met, the flow carries on immediately via **Met**. If you have not entered a condition, it is always met
- At each check Tillor reads the records of the event again, as with a [delay](#gegevens-worden-opnieuw-gelezen). A condition such as `invoice.paymentStatus` is `PAID` therefore sees the payment as soon as it is there
- An interval under 5 minutes becomes 5 minutes
- While it waits, the run gets the status **Waiting**. Pausing and changing the flow work the same as with [Delay](#wat-er-tijdens-het-wachten-gebeurt)

## Wait for an event [#wachten-op-een-gebeurtenis]

Pauses the flow until something happens in Tillor, for example that the invoice has been paid.

| Field | What you enter |
|---|---|
| **Event** | What you are waiting for. The same list as with the [trigger](/automatiseringen/triggers#als-er-iets-gebeurt). Required |
| **Only for the same record** | Only carries on if the event is about the record that started the flow. On by default |
| **Stop waiting after** | How long the step waits at most. 7 days by default |

The step has two outputs: **Received** (the event came) and **Timed out** (the wait is over without an event). If **Only for the same record** is on, a third output is added, **Deleted**. You use it when the record of the flow was deleted while the flow was waiting.

Note the following:

- With **Only for the same record** on, for example, only the payment of the invoice that started the flow counts. If you turn it off, every event of that type lets the flow carry on
- If you connect **Deleted** to nothing, Tillor stops the waiting flows of that record and deletes the tasks the flow created and only the flow could complete. If you do connect the output, the flow carries on there
- If the flow starts without a record, for example with **Every day at a time**, every event of that type counts
- An event that a step of an automation causes itself counts too. Waiting flows therefore also carry on because of work by **Workflow**
- After **Received**, the data of the event you were waiting for is in the variables, without the colleague who caused it. If you wait for `invoice:paid`, then `{invoice.paymentStatus}` gives the new state afterwards
- While it waits, the run gets the status **Waiting**. Pausing and changing the flow work the same as with [Delay](#wat-er-tijdens-het-wachten-gebeurt)

## Ask for a decision [#vraag-om-een-beslissing]

Creates a task with buttons that you define yourself, and waits until someone chooses a button. That way you build in a moment where a person looks along, for example before the flow blocks a customer or books an invoice. Each option is a button on the task and an output of the step.

| Field | What you enter |
|---|---|
| **Task title** | The title of the task. Required |
| **Description** | Tell your colleague what has to be decided |
| **Options** | The buttons on the task. See below. At least one |
| **Assign to** | Pick one or more colleagues |
| **Assign to groups** | Pick one or more groups |
| **Link to** | The records the task appears on, such as the customer or the invoice. Pre-filled with the records known at this step |
| **Stop waiting after** | How long the step waits at most. 3 days by default |

### Setting up options [#opties-instellen]

1. Under **Options**, click **Add option** and enter the name, for example **Approve**. That name appears on the button and on the output
2. Click the coloured box to the left of the name (**Icon and colour**) to pick a colour and an icon. An icon is optional
3. Turn on **Ask for a note** if the colleague has to give a reason with this choice
4. Turn on **Ask for confirmation** if the colleague has to confirm first. You then enter a **Confirmation title** and **Confirmation message** and pick a **Severity** from **Info**, **Warning** or **Destructive**. You can use variables in these texts
5. Repeat this for each option. You can create up to 8 options

If the list is still empty, the **Approve / Reject** button immediately sets up two options: a green **Approve** and a red **Reject**. Each option needs a name, otherwise Tillor says **Every option needs a name.** Without options Tillor says **Add at least one option.**

### Outputs [#uitgangen]

The step has one output per option, with the name and colour of that option, plus always **Timed out**.

| Output | When |
|---|---|
| The name of an option | Someone chose that button on the task |
| **Timed out** | The wait is over without a choice, or the task was deleted |

Note the following:

- The buttons are on the task card, in the task list and in the task itself. Such a task has no tick: you cannot simply complete it, only choose a button. After the choice the task is **Completed** and it shows which option was chosen. See [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen)
- Anyone assigned to the task can choose, also via a group, and so can administrators. If you assign nobody, anyone who can see the task can choose
- The task gets priority **High**. It is in the name of **Workflow**
- If the task is deleted before anyone chose, the flow carries on via **Timed out**. After **Timed out** because of the wait, the task stays
- Later steps can use `{approvalTask.id}`, `{approval.decision}`, `{approval.label}`, `{approval.note}` and `{approval.decidedBy.name}`. `{approval.label}` is the name of the chosen option and `{approval.note}` the note the colleague entered
- While it waits, the run gets the status **Waiting**. Pausing and changing the flow work the same as with [Delay](#wat-er-tijdens-het-wachten-gebeurt)

<Callout type="info" title="In a test you pick the output yourself">
A [test run](/automatiseringen/testen-en-uitvoeringen) cannot know whether you are open, what a colleague decides and whether a record exists. Under **What happens at these steps?** you therefore pick the output of **Open now?**, **At most once per period**, **Look up a record**, **For each**, **Wait until**, **Wait for an event** and **Ask for a decision** yourself. With **For each** the test goes through the output you pick, **For each** or **Done**, not both.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- An output you do not connect lets the run end there.
- With a wait step the run gets the status <Status tone="info">Waiting</Status> and carries on later. A paused automation stops waiting runs as soon as the wait is over.
- After a wait Tillor reads the data again, so the steps see the current situation.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says Add a condition">
An **If / else** step needs at least one condition. Click **Add condition**.
</Accordion>
<Accordion title="Tillor says A delay of 0 does nothing">
Enter a number greater than 0 under **Duration**.
</Accordion>
<Accordion title="The flow always goes via Default">
A **Switch** compares the value exactly, including capitals. Choice values use Tillor's notation, such as `RENTAL_CARAVAN`. If the field is empty, the flow also goes via **Default**.
</Accordion>
<Accordion title="Tillor says Add at least one option or Every option needs a name">
An **Ask for a decision** step needs at least one option with a name. Under **Options**, click **Add option**.
</Accordion>
<Accordion title="The run stays on Waiting">
The flow is waiting for a time, condition, event or decision. On the **Runs** tab you can see when it carries on or times out. With **Wait until** that is after 7 days by default, with **Ask for a decision** after 3 days.
</Accordion>
<Accordion title="The task of Ask for a decision has disappeared">
If the task is deleted before anyone chose, the flow carries on via **Timed out**. See [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen).
</Accordion>
</Accordions>


# Issues and enabling (/en-GB/automatiseringen/problemen)

Tillor keeps checking your flow while you build it. As long as there are open issues, you cannot enable the automation. That prevents a flow that cannot work from trying to send real reminders or tasks.

## Where you see the issues [#waar-zie-je-de-problemen]

- Every step with an issue shows a small warning number
- In the panel on the right, the issues of the selected step are in an orange block above the settings
- At the top of the panel is a button with the total, for example **3 issues**. Click it for the list and click a message to jump to the step
- In the overview of automations there is a label such as **3 issues** next to the name, and an **Issues** filter

<DocScreenshot src="/screenshots/automatiseringen/issues.png" alt="Button 1 issue at the top of the panel with the message Title is required" />

## Why can't I enable it [#waarom-kan-ik-niet-inschakelen]

The **Active** switch does not work as long as there are issues, with the text **Fix the open issues first**. In the overview you cannot turn on the automation's switch either.

If the automation is already on, you cannot save changes that have issues. A flow that is running has to stay valid. Fix the issues, or pause the automation first.

## What the messages mean [#wat-de-meldingen-betekenen]

| Message | What is going on | What you do |
|---|---|---|
| **Add a trigger to start with.** | The flow has no trigger | A flow always needs at least one trigger. Drag **When this happens** from the list on the left onto the canvas |
| **This event no longer exists. Pick another one.** | The event of the trigger no longer exists | Pick another one under **Event** |
| **Not connected, so this step never runs.** | No line leads to the step | Connect the step to an output of another step, or delete it |
| **This step is part of a loop. A flow can only go forward.** | A line comes back to an earlier step | Delete the line that points back. A flow cannot run in a circle |
| **[Field] is required.** | A required field is empty, such as the **Title** of a task | Fill in the field. Required fields have an asterisk |
| **[Field]: [variable] is not available at this step.** | You use a variable that does not exist at this step | Pick a variable from the list behind the **Variable** button. Also check that the step that produces the variable comes earlier in the flow |
| **[Field] is not valid JSON.** | The **Payload** or **Body** is not correct JSON | Check braces, commas and quotation marks. Variables are allowed |
| **Add at least one option.** | An **Ask for a decision** step has no options | Under **Options**, click **Add option** |
| **Every option needs a name.** | An option of **Ask for a decision** has no name | Enter the name or delete the option |
| **Add a condition.** | An **If / else** step has no conditions | Click **Add condition** |
| **A condition has no valid field.** | The field of a condition is empty or unknown | Pick or type a field that is in the list behind **Variable** |
| **Enter a value for [variable].** | A condition has a comparison but no value yet | Enter the value, or pick a comparison such as **is empty** that needs none |
| **[Field]: [variable] is not a known format.** | After the `\|` you use a format that does not exist | Use `currency`, `number`, `date`, `datetime`, `time`, `upper` or `lower`. See [Formatting a value](/automatiseringen/variabelen#een-waarde-opmaken) |
| **[Field]: [variable] is not a unit.** | You write a date shift with a unit that does not exist | Use `minutes`, `hours`, `days`, `weeks` or `months` |
| **[Field]: custom field [variable] does not exist.** | You use a custom field that does not (or no longer) exist | Pick an existing field from the list behind **Variable** |
| **[Field]: [variable] has a format or date shift, which only works in texts.** | You use a format in the code field of **Run code** | Compute it in the code |
| **[Field]: [variable] is not a variable name.** | The name of a result contains characters that are not allowed | Use letters, digits and dots, such as `result` or `result.names` |
| **A delay of 0 does nothing.** | The delay is set to 0 | Enter a duration greater than 0 |
| **The path must start with / and stay inside your organization's API.** | The **Path** of an API request is not allowed | Start the path with a single `/` and do not put `..` or `\` in it |
| **The URL must start with https://.** | The **URL** of an API request is not secure | Use an address that starts with `https://` |
| **The cron expression is not valid. Use five fields, such as 0 8 * * 1.** | The cron expression is not correct | See [On a cron expression](/automatiseringen/triggers#volgens-een-cron-expressie) |

## What Tillor cannot check beforehand [#wat-tillor-niet-vooraf-kan-controleren]

Some errors only come to light when the flow really runs.

- A URL made up of variables can only be checked once it has been filled in
- For events whose data is not described, Tillor does not check the variables
- Whether a record exists, whether an invoice can be sent or whether another server is reachable only turns out during a run

A flow without messages is therefore not necessarily a flow that always succeeds. Test it with [Testing and runs](/automatiseringen/testen-en-uitvoeringen) and check the first real runs.

<Callout type="info" title="An event that disappears">
If an event or a field your flow relies on changes, you see it as a message at the step concerned. Adjust the step before you enable the automation again.
</Callout>


# Testing and runs (/en-GB/automatiseringen/testen-en-uitvoeringen)

In the editor you work with two tabs to check that a flow does what you want: **Test run** for a trial and **Runs** for what really happened. You open them on the right in the panel. The fourth tab, **History**, shows earlier versions of the flow, see [Earlier versions](/automatiseringen/aan-de-slag#eerdere-versies).

## A test run [#een-testuitvoering]

Choose the **Test run** tab. A test goes through the flow with sample data and shows which steps it would take.

<Callout type="info" title="Nothing real happens">
A test run sends nothing, creates nothing and changes nothing. Delays are skipped, so you see the end result straight away. Actions only show what they would do, with the text **Not carried out in a test.**
</Callout>

<DocScreenshot src="/screenshots/automatiseringen/test-run.png" alt="Test run tab with sample data and the result per step" />

### Sample data [#voorbeeldgegevens]

At the top is **Test with a real record**. For each record of the trigger, such as **Occupation**, choose a record via **Choose a record** (search by name or number). Tillor loads the record as it is now, with the records it refers to, into the sample data. The test still sends, creates and changes nothing.

Under **Sample event data** is the data the test works with, in JSON form. If the automation has already run for real, the test starts with the data of the last real run. Otherwise Tillor fills in a sample that has the shape of the event: a text becomes *example*, a number 1 and a date the current moment.

Change the values to try other cases, for example a different terrain type or an invoice with a different status. If the text is not valid JSON, it says **The sample data is not valid JSON.** and you cannot start the test.

If the flow contains an **API request**, there is also a **Sample API response** field. Paste the response you expect from the request there. With it the test can go through the steps after the request, and Tillor offers the fields of the response as variables. See [Using an API response](/automatiseringen/variabelen#een-api-antwoord-gebruiken).

### What happens at these steps [#wat-gebeurt-er-bij-deze-stappen]

For some steps the outcome depends on the outside world: **Send webhook**, **API request**, actions with a **Skipped** or **Error** output, and logic such as **Open now?**, **Look up a record**, **Wait for an event** and **Ask for a decision**. Under **What happens at these steps?** you choose per step which output the test carries on through. That way you also test the path for when things go wrong.

### The result [#het-resultaat]

Click **Run test**. You get to see the steps in order, with for each step:

- the filled-in values, for example the title of a task as it would be created
- for a condition, per line what was compared and whether it matched. Green is passed, red is not, with the value that was actually there (*was …*)
- which output the flow carried on through (**Continues on: Yes**)
- for a delay, until when it would wait

After running, the button is called **Run again**. The test plays the steps one by one (**Step 2 of 5…**). With **Show all** you skip that playback. On the canvas the path the test took is coloured, and the steps that did not get their turn are dimmed. Click a step name in the result to jump to that step. At the bottom it says **Finished after 5 steps.**

If the filter under **Only when** does not match your sample data, you see **The trigger's filter does not match this data, so the flow would not start.** Then check which condition is red. With **Clear** you remove the result from the canvas again.

### What a test does not show [#wat-een-test-niet-laat-zien]

- Whether an invoice can really be sent, whether an endpoint is reachable, or whether an API path exists
- What records look like after a delay. The test works with your sample data and reads nothing again
- Errors that only occur with real data, such as an empty field

So always take a look at the first real runs on the **Runs** tab.

## Real runs [#echte-uitvoeringen]

The **Runs** tab shows the last 20 real runs of this automation, the newest at the top. The list refreshes itself about every 15 seconds. As long as nothing has started yet, it says **No runs yet. Enable the automation and wait for its event.**

Each run shows the start time, the number of steps or (when waiting) when it carries on, and a status.

| Status | What it means |
|---|---|
| **Running** | The run is going at this moment |
| **Waiting** | The run is in a [delay](/automatiseringen/logica#vertraging), waiting for an event or for an approval, and carries on later |
| **Completed** | The flow has been run through to the end |
| **Failed** | A step could not be carried out. The message is shown as **Failed: …** |
| **Canceled** | The run stopped because the automation was paused or deleted while it was waiting |

Click a run to open it. You then see:

- all the steps that were taken, with the time and what the step did
- the filled-in values, for example the title the task really got
- for a condition, which rules matched
- for a failed step, the error message, which may be in English

On the canvas the path this run took is coloured. Steps that did not get their turn are dimmed. Click a step name to jump to that step.

Below the steps is a button such as **3 payloads**. It shows the data the run started with and what each action produced, such as the created task id or the response of an API request. That way you can check which values a variable had.

At the bottom of an opened run is also a **Trace**: a code of letters and digits. If something is wrong with a run, pass that code on to support. That way we can find exactly this run.

<Callout type="info">
Events that did not pass the filter under **Only when**, or for which the automation already ran with **Run once per record**, do not start a run and are therefore not in the list.
</Callout>

In the overview of automations, each automation shows the time of its last run, with a small bar per recent run next to it.

## What happens next? [#wat-gebeurt-er-daarna]

- After a test run nothing has changed in Tillor. Only when you turn on **Active** does the automation really run.
- Real runs stay on the **Runs** tab. It shows the last 20.
- A failed run results in an email to whoever made the automation, at most one per hour.

## Problems? [#problemen]

<Accordions>
<Accordion title="The sample data is not valid JSON">
Tillor shows **The sample data is not valid JSON.** and does not let the test start. Check braces, commas and quotation marks.
</Accordion>
<Accordion title="The trigger's filter does not match this data">
With this sample data the flow would not start. Look at which condition is red and adjust the data or the condition.
</Accordion>
<Accordion title="I see no runs">
Tillor shows **No runs yet. Enable the automation and wait for its event.** Events that did not pass the filter are not in it. See [Frequently asked questions](/automatiseringen/veelgestelde-vragen#waarom-start-mijn-automatisering-niet).
</Accordion>
<Accordion title="The test succeeds, but the real run fails">
A test sends nothing and does not read records again. Whether an invoice can be sent or an address is reachable only turns out for real. Open the run for the error message and the data per step. Need help from support? Pass on the **Trace** code of the run.
</Accordion>
</Accordions>

## A run that will not start [#een-uitvoering-die-niet-wil-starten]

See [Frequently asked questions](/automatiseringen/veelgestelde-vragen#waarom-start-mijn-automatisering-niet) for a checklist.


# Triggers (/en-GB/automatiseringen/triggers)

The trigger is the starting moment of an automation: the "when". It sits at the top of every flow, under the name **When this happens**. An example: *start when an occupation ends*. It also determines which data the steps after it can use. A flow can have several triggers. Each trigger starts a run of its own, with its own filter. You add one from the list on the left. You cannot delete the last trigger.

<DocScreenshot src="/screenshots/automatiseringen/trigger-settings.png" alt="Trigger selected with the fields Starts from and Event, the Only when filter and the data the event provides" />

## What the automation starts on [#waar-start-de-automatisering-op]

Under **Starts from** you choose one of seven starting moments.

| Choice | Starts when |
|---|---|
| **When something happens** | An event takes place in Tillor, such as an occupation that ends or an invoice that is paid |
| **Invoice is overdue** | A booked invoice is still open after its due date |
| **Incoming webhook** | Another system sends a message to the automation's own address |
| **A task action is chosen** | Someone picks a choice button on a task that is linked to this automation |
| **A date is reached** | A date of a record is reached, optionally some time before or after it. For example one day before the arrival of a reservation |
| **Every day at a time** | It is the chosen time every day |
| **On a cron expression** | It is the turn of the schedule you give |

So you first choose the kind of starting moment, and then the details. If you choose a different starting moment, the filters under **Only when** are cleared. They were written for the previous choice and no longer fit.

## When something happens [#als-er-iets-gebeurt]

Under **Event** you choose what the automation should start on. Click the field and type to search, for example *occupation* or *invoice*. The events are written in Tillor's notation, such as `occupation:ended`: first what it is about, then what happened.

These are the events you need most often:

| Event | Starts when |
|---|---|
| `occupation:ended` | An occupation ends |
| `reservation:created` | A reservation is created |
| `reservation:updated` | A reservation is changed |
| `customer:created` | A customer is created |
| `customer:updated` | A customer is changed |
| `invoice:created` | An invoice is created |
| `invoice:updated` | An invoice is changed |
| `invoice:paid` | An invoice has been paid |
| `payment:created` | A payment comes in |
| `task:created` | A task is created |
| `task:status-changed` | The status of a task changes |
| `task:assigned` | A task is assigned to someone |
| `task:action-chosen` | Someone picks a choice button on a task |
| `integration-alarm:created` | A meter raises an alarm |
| `comment:created` | A comment is posted |
| `document:created` | A document is added |
| `signatureRequest:updated` | A signature request is updated |
| `signatureRequest:completed` | All signers of a signature request have signed |
| `mandate-agreement:signed` | A customer has signed a SEPA mandate |
| `mandate-agreement:activated` | A SEPA mandate has become active |
| `mandate-agreement:expired` | A request for a SEPA mandate has expired without a signature |
| `mandate-agreement:failed` | The activation of a SEPA mandate was refused or failed |
| `productPriceChange:applied` | A [scheduled product price](/producten/prijzen-plannen) takes effect |

This is the same list as that of the [webhooks](/ontwikkelaars/events). So you can use every event for which Tillor can send a webhook. A few events that occur extremely often, such as the physical state of barriers, typing in the inbox, controller logs and vehicle presence, are not in the list.

<Callout type="info" title="Missing an event?">
Under the **Event** field is the link **Missing an event? Request it**. See [Requesting a step or event](/automatiseringen/aan-de-slag#een-stap-of-gebeurtenis-aanvragen).
</Callout>

### Which data you get [#welke-gegevens-krijg-je-mee]

Most events come with a record, such as an occupation, an invoice or a task. That record, plus the records it refers to, are then available as variables in the steps. With `occupation:ended` you can use, for example:

- `{occupation.terrain.name}` for the name of the terrain
- `{occupation.customer.firstName}` for the customer's first name
- `{occupation.reservation.displayId}` for the number of the reservation. Not every occupation has a reservation: in that case this stays empty

There are also always `{triggeredBy.name}` and `{triggeredBy.id}`: the colleague who caused the event. If the event was caused by the system, for example by a bank synchronisation, those fields are empty.

Under the trigger's settings is **Data this event provides**. There you see exactly which variables you can use. For an event whose data is not described, Tillor says there is nothing to choose. Variables that you type yourself still work then. See [Variables and templates](/automatiseringen/variabelen).

## A task action is chosen [#er-wordt-een-taakactie-gekozen]

Some tasks have choice buttons instead of a tick box, for example from [Ask for a decision](/automatiseringen/logica#vraag-om-een-beslissing). A button can be linked to an automation. With this trigger, that automation starts as soon as someone picks that button. See also [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen).

Linking a button to an automation is not done in the flow editor. If you need this, ask your Tillor administrator or support.

The steps receive the data of the task, for example `{task.name}` and `{task.id}`, plus `{action.label}` (the name of the chosen button) and `{note}` (the note the colleague filled in, if the button asked for one). Under **Data this event provides** you see the full list.

## Invoice is overdue [#factuur-is-vervallen]

This trigger starts for every invoice that:

- is booked (drafts and cancelled invoices do not count)
- is not a credit note
- still has an outstanding amount
- has a due date before today

A run of its own starts for each such invoice. The data of the invoice and the customer is available as `{invoice.…}`, for example `{invoice.displayId}`, `{invoice.amountOutstanding}` and `{invoice.customer.firstName}`.

If you turn **Run once per record** off, the automation starts for the same invoice at most once a day for as long as it is overdue. If you leave it on, it starts exactly once for each invoice. That is usually what you want for a reminder.

Under **Due for a reminder** you choose how long the invoice must already have been open, the same rule as in the invoice list. Turn on **Exclude customers who do not receive automatic reminders** to skip customers who have that set in their invoicing settings. An invoice that has itself been taken out of the automatic reminders does not start the flow either.

## Incoming webhook [#inkomende-webhook]

A webhook is a message that another system sends to an address. With this trigger, that system starts the automation, for example your website, a form or a booking platform. Every automation gets a secret address of its own.

1. Under **Starts from** choose **Incoming webhook**
2. Save the automation. The URL appears under **Address**
3. Click **Copy** and set the address in the other system
4. Turn the automation on

The other system sends a `POST` with JSON to that address. The content is then available as `{body.…}`, for example `{body.email}` or `{body.reservering.nummer}`, and parameters in the URL as `{query.…}`. With **Only when** you can filter on those fields too.

This is how it works otherwise:

- The address is the secret. Anyone who knows it can start the automation. So share it only with the system that needs it
- If the address leaks, click **New address** and save. The old address stops working from then on
- A disabled automation or a wrong address gives a `404` error
- The content may be at most 100 KB
- Each call starts one run per webhook trigger in the flow. The address belongs to the first webhook trigger. **New address** on that trigger replaces it
- No record is linked to it, so **Run once per record** has no effect

### Ignoring repeats [#herhalingen-negeren]

If the other system sometimes sends the same call twice, **Ignore repeats** prevents the flow from starting twice. Tillor remembers a key of the call. If the same key comes in again, nothing starts.

| Choice | What the key is |
|---|---|
| **Every call starts the flow** | There is no key. The default |
| **From a header** | The value of a header that you choose under **Header name**, for example `Idempotency-Key` |
| **From the JSON body** | The value of a field in the JSON, which you choose under **Field**, such as `id` or `data.eventId` |
| **Same JSON body** | The whole content. A call with exactly the same content counts as a repeat |

Under **Remember the key for** you choose how long the key applies, in hours, days or weeks. After that time the same key starts the flow again. At 0 the key applies until you delete the automation. A call without the chosen header or without the chosen field is rejected.

## A date is reached [#een-datum-is-bereikt]

This trigger starts on a date of a record. Under **Date** you choose any date field of a record that Tillor also sends along with events, written as record and field. A few examples:

| Date | Record |
|---|---|
| `reservation.checkIn` | The arrival date of a reservation |
| `reservation.checkOut` | The departure date of a reservation |
| `invoice.dueDate` | The due date of an invoice |
| `task.dueDate` | The deadline of a task |
| `occupation.paidUntil` | Until when an occupation is paid |
| `accessMethod.periodTo` | The end of the validity of a QR code, number plate or other access method |
| `nfcTag.activatedUntil` | Until when an NFC tag is activated |
| `mandateAgreement.expiresAt` | When a request to sign a SEPA mandate expires |
| `customer.birthday` | A customer's date of birth |
| `contact.birthday` | A contact person's date of birth |

By default the trigger starts once, on the date itself. Turn on **Repeat every year** to count only the day and month: the flow then starts again every year, such as on the birthday with `contact.birthday`. A 29 February falls on 28 February in other years.

You can also choose data that is stored with a record as extra fields. `document.userMetadata.insuranceExpiryDate` is the expiry date of a document, such as an insurance payment proof. A date without a time like that counts as midnight (UTC, the international standard time). With **Only when** you then limit the trigger to one type, for example `document.userMetadata.documentType` is `INSURANCE_PAYMENT_PROOF`, and to active documents with `document.status` is `ACTIVE`.

With **How long** and **Before or after** you shift the moment. *1 day* and **Before** on `reservation.checkIn` starts the flow a day before the arrival. At 0 it starts on the date itself. A date without a time counts as midnight.

With **Time** you choose when on that day the flow starts. **The time in the date** uses the moment that is in the field, such as the arrival time of a reservation. **Fixed time of day** starts on the day of the date at the hour and minute you choose, in your organisation's time zone. That is how `contact.birthday` with **Repeat every year** starts every year at 09:00 on the birthday. **How long** then counts from that time: *1 day* and **Before** starts the day before at 09:00, even if the clocks change that night.

A run of its own starts for each record, with the data of that record as variables, for example `{reservation.displayId}` and `{reservation.customer.firstName}`. With **Only when** you limit it, for example to reservations with the status booked only.

This is how it works otherwise:

- The flow starts once per record and per moment. If the date moves to later, for example because a guest arrives later, it starts again at the new moment
- If the moment had already passed when you saved or enabled the automation, it no longer starts for it
- Missed moments, for example during maintenance, are still caught up by Tillor for up to an hour afterwards

## Every day at a time [#elke-dag-op-een-uur]

Under **Hour** choose an hour (0 to 23) and under **Minute** a minute from 0 to 59. The time is the time in your organisation's time zone.

The steps receive `{now}`: the moment the run started.

## On a cron expression [#volgens-een-cron-expressie]

Choose a rhythm, such as every day, every Monday at 08:00, or the odd Mondays (the 1st, 3rd and 5th). Under **Custom** you set the interval, the weekdays and the time, down to the minute. Under **Cron expression** you write the schedule yourself.

A cron expression is a short way of writing a repeating time. It has five parts, separated by a space: **minute**, **hour**, **day of the month**, **month** and **weekday**.

| Expression | Meaning |
|---|---|
| `0 8 * * 1` | Every Monday at 08:00 |
| `7 8 * * 1` | Every Monday at 08:07 |
| `30 7 * * 1-5` | Every working day at 07:30 |
| `0 9 1 * *` | On the first of every month at 09:00 |
| `0 8 * * 1#1,1#3,1#5` | Every odd Monday (1st, 3rd and 5th of the month) at 08:00 |
| `0 8 * * 1L` | The last Monday of the month at 08:00 |
| `0 8 * * 1 W2:2026-10-05` | Every two weeks on Monday at 08:00, starting from the week of 5 October 2026 |
| `*/15 * * * *` | Every quarter of an hour |
| `* * * * *` | Every minute |

In each part you can use a number, a list with commas (`8,17`), a range (`1-5`), a step (`*/15`) or an asterisk (`*`, every value). Weekday 0 and 7 are both Sunday. `1#2` is the second Monday, `1L` the last. A sixth field `W2:2026-10-05` repeats every two weeks, counted from that week. Names such as *MON* or *JAN* do not work. If you fill in both a day of the month and a weekday, the automation starts on either of the two.

If the expression is invalid, Tillor reports that at the trigger. The times apply in your organisation's time zone.

## Exactly when does a schedule start [#hoe-laat-start-een-schema-precies]

<Callout type="warn" title="A schedule starts in the minute in which it is due">
Tillor checks every minute which schedules are due. An automation that should start at 08:07 starts in that minute. This applies to **Invoice is overdue**, **A date is reached**, **Every day at a time** and **On a cron expression**.
</Callout>

A schedule starts at most once per minute. A check that only runs in the next minute does not catch up on the previous minute.

Events start immediately, without this delay.

## Only when [#alleen-wanneer]

With **Only when** you let the automation start only if the data matches. That way you start, for example, only for static caravans, or only for invoices above a certain amount. Leave it empty to start for every event of this type.

1. Click **Add condition**
2. Choose the field with the **Variable** button (or type the path, for example `invoice.status`)
3. Choose how you compare
4. Fill in the value. For fields with a fixed choice, such as a status, a terrain type or a colleague, you choose from a list

You can use the following comparisons:

| Choice | Matches when |
|---|---|
| **is** | The field equals the value |
| **is not** | The field does not equal the value |
| **contains** | The value occurs somewhere in the field |
| **is greater than** | The field is greater than the value (for numbers and dates) |
| **is less than** | The field is less than the value (for numbers and dates) |
| **is one of** | The field equals one of the chosen values |
| **is empty** | The field is empty |
| **is not empty** | The field is not empty |

Capitals do not matter. Numbers are compared as numbers, so 10 is greater than 9.

If you have more than one condition, you choose how they work together: **All must match** or **Any may match**.

<Callout type="info">
Events that are held back by the filter do not start a run and so leave no trace on the **Runs** tab. If you want to see whether your filter is right, use **Test run**: there you see for each condition whether it matched.
</Callout>

## Run once per record [#eén-keer-per-record-uitvoeren]

With **Run once per record** the automation starts at most once per invoice, reservation or other record, however often the event occurs for it.

That is especially handy for events that come back often, such as `invoice:updated`: an invoice is changed dozens of times, but you only want to send one reminder. Tillor remembers per record that the automation has already started. That memory disappears when you delete the automation.

It only works for events that come with a record, and for **Invoice is overdue** and **A date is reached**. With **A date is reached** it means: even if the date moves later, the flow does not start again. For a schedule such as **Every day at a time** it has no effect.

## What happens next? [#wat-gebeurt-er-daarna]

- Every time the starting moment occurs and the filter matches, a run starts with the data of that moment as variables.
- An event starts immediately. A date, hour or schedule starts in the minute in which it is due.
- If the filter does not match, nothing starts and there is no trace on the **Runs** tab.

## Problems? [#problemen]

<Accordions>
<Accordion title="The automation does not start on my event">
Check whether the automation is on, whether you chose the right **Event** and whether the filter under **Only when** is not too strict. Test with the data of a real case on the **Test run** tab. More in [Frequently asked questions](/automatiseringen/veelgestelde-vragen#waarom-start-mijn-automatisering-niet).
</Accordion>
<Accordion title="Tillor says The cron expression is invalid">
Use five fields separated by a space, such as `0 8 * * 1`. Names like *MON* do not work.
</Accordion>
<Accordion title="An incoming webhook gives a 404 error">
The automation is off or the address is not right. Turn the automation on and copy the address again.
</Accordion>
<Accordion title="My filter disappeared when I chose a different starting moment">
With a different starting moment the filters under **Only when** are cleared, because they were written for the previous starting moment. Add them again.
</Accordion>
<Accordion title="The flow does not start again for the same invoice">
**Run once per record** is on. It then starts at most once per invoice, reservation or other record.
</Accordion>
</Accordions>

## Read more [#meer-lezen]

<Cards>
  <Card
    title="Conditions, switches and delays"
    href="/automatiseringen/logica"
    description="Make the flow split and make it wait"
  />
  <Card
    title="Variables and templates"
    href="/automatiseringen/variabelen"
    description="Use the data of the event in your steps"
  />
</Cards>


# Variables and templates (/en-GB/automatiseringen/variabelen)

With variables you make texts that differ from case to case. You write a variable between curly braces and Tillor fills in the real value as soon as the automation runs.

An example of a task title:

```text
Controleer {occupation.terrain.name}
```

If the occupation ends on terrain 12, the task is called *Controleer 12*.

## Inserting a variable [#een-variabele-invoegen]

Above every text field where variables work, there is the **Variable** button. Click it and you see a list of all available data, grouped by record. Type to search (**Search variables**) and click a row. Tillor puts the variable at the position of your cursor.

<DocScreenshot src="/screenshots/automatiseringen/variables-picker.png" alt="Variable button at the Title field with the list of available variables open" />

You can also just type a variable yourself. Under the field a grey box shows what the text looks like with sample data, so you can see straight away whether it is right.

Variables work in text fields such as titles, descriptions, subtasks, messages, the id of a customer, invoice or other record, the path or URL of an API request, the body, the payload of a webhook, the name of the webhook event and the values of headers. For the last two the **Variable** button is missing, but a variable that you type yourself is still filled in. Tillor does not check those two fields for errors and shows no preview for them.

In fields where you choose a piece of data to compare with, you write the variable without curly braces. That applies to **Only when**, **If / else** and **Until** under **Wait until** (for example `invoice.status`), to the **Field** of a **Switch** and to the **Date** of a **Delay**.

## Which variables are there [#welke-variabelen-zijn-er]

| Variable | Available | Content |
|---|---|---|
| `{occupation.…}`, `{invoice.…}`, `{task.…}`, `{reservation.…}` and others | After an event | The fields of the record the event is about. The name of the record is also the start of the variable |
| `{occupation.terrain.name}` | After an event | Fields of the records the record refers to, such as the customer or the terrain. This works one level deep |
| `{triggeredBy.name}`, `{triggeredBy.id}` | Always | The colleague who caused the event. Empty if the system did |
| `{invoice.…}` | With **Invoice is overdue** | The fields of the overdue invoice and the customer |
| `{reservation.…}`, `{task.…}` and others | With **A date is reached** | The fields of the record whose date was reached, plus the records it refers to |
| `{now}`, `{today}` | Always | The moment the step runs, and midnight of that day in the organisation's time zone. Together with a shift (below), `{today + 1 day}` gives tomorrow |
| `{threadId}`, `{messageId}` | With events about inbox messages, such as `inbox:message-created` | The id of the conversation and of the message |
| The fields of the event | After **Wait for an event**, via **Received** | The data of the event that was waited for. It replaces the data of the same records from the start of the flow |
| `{createdTask.id}`, `{createdTask.name}` | After **Create task** | The task that was just created |
| `{foundTask.id}`, `{foundTask.name}`, `{foundTask.priority}`, `{foundTask.status}` | After **Find task**, via **Found** | The task the step found |
| `{updatedTask.id}`, `{updatedTask.status}` | After **Set task status** | The task whose status was changed |
| `{updatedTask.id}`, `{updatedTask.priority}` | After **Set task priority** | The task whose priority was changed |
| `{updatedTask.id}` | After **Update task** | The task that was changed |
| `{foundDocument.id}`, `{foundDocument.name}`, `{foundDocument.status}`, `{foundDocument.userMetadata.documentType}`, `{foundDocument.userMetadata.insuranceExpiryDate}` | After **Find document**, via **Found** | The document the step found |
| `{updatedDocument.id}` | After **Update document** | The document that was changed |
| `{response.status}`, `{response.body}`, `{response.data.…}` | After **API request** | The response to the request |
| `{foundCustomer.…}`, `{foundInvoice.…}`, `{foundReservation.…}` and others | After **Look up a record**, via **Found** | The fields of the record the step found, plus the records it refers to. The name is `found` plus the record type: `foundCustomer`, `foundReservation`, `foundOccupation`, `foundInvoice`, `foundPayment`, `foundTerrain`, `foundTask`, `foundDocument`, `foundAccessMethod`, `foundNfcTag`, `foundMeter`, `foundInboxThread` or `foundInboxMessage` |
| `{body.…}`, `{query.…}`, `{receivedAt}` | After **Incoming webhook** | The JSON body, query parameters and time of receipt of the webhook call |
| Every target name from **Map variables** | After **Map variables** | What you fill in as the target in that step, for example `{invoice.displayId}` after `invoice` ← `{foundInvoice}` |
| `{item.…}` | In the steps after **For each** | The fields of the item the step is now running for, such as `{item.id}` |
| `{approvalTask.id}`, `{approval.decision}`, `{approval.label}`, `{approval.note}`, `{approval.decidedBy.name}` | After **Ask for a decision**, via an option | The task, the chosen option, the name of that option, the note and the colleague who chose |
| `{task.…}`, `{action.label}`, `{note}` | With **A task action is chosen** | The task, the chosen button and the note filled in with it |
| `{createdComment.id}` | After **Add a comment** | The comment that was just posted |
| `{bookedInvoice.displayId}` | After **Book invoice**, via **Done** | The invoice number of the booked invoice |
| `{paymentLink.url}` | After **Create payment link**, via **Done** | The link the customer can pay online with |
| `{consumptionInvoice.id}` | After **Invoice consumption**, via **Done** | The invoice for the meter consumption |
| `{extendInvoice.id}` | After **Draft extension invoice** | The draft invoice that extends the occupation |
| `{createdAccessMethod.id}`, `{createdAccessMethod.value}` | After **Create access method** | The new access method and its value, such as the code of a QR code or PIN code |
| `{error.message}`, `{error.step}` | After an action with **Continue when this step fails**, via **Error** | The error message and the name of the step that failed |

Exactly which fields a record has, you see in the list behind the **Variable** button. At the trigger there is also the overview **Data this event provides**.

### Only what comes earlier in the flow [#alleen-wat-eerder-in-de-flow-komt]

A step can only use variables from the trigger that reaches it and from steps that come earlier on the same path. If several triggers reach the same step, only the variables that each of those triggers provides are available. A field from an earlier step counts if each of those triggers also passes that step. If you use a variable that does not exist at that point, Tillor reports **[Field]: [variable] is not available at this step.** A flow with such a message cannot be enabled.

Some records keep extra data in one field, such as the document data in `userMetadata`. Every key below it is a variable: `{document.userMetadata.documentType}`, `{document.userMetadata.insuranceExpiryDate}` or another key. The known keys, such as the type and expiry date of a document, are also in the list and you can compare them as a date. A date without a time, such as `2026-10-07`, appears in a message as `07-10-2026`.

Variables of **For each** (`{item.…}`) only exist in the steps after the **For each** exit, not after **Done**. Variables of an exit you did not take do not exist either: `{paymentLink.url}` is only there if the step ran via **Done**, and `{foundTask.id}` only after **Found**.

For events whose data is not described, Tillor cannot check which variables exist. Then you do not get that message. So check such flows extra carefully with a test run.

### A new value replaces the old one [#een-nieuwe-waarde-vervangt-de-oude]

A second **API request** in the same flow replaces the `response` of the first. The same goes for `createdTask` after a second **Create task**, for `foundTask` after a second **Find task** or **Look up a record** on **Task**, and for `error` after a second failed step. So use the data from a response in the step that directly follows it.

## How values are filled in [#hoe-waarden-worden-ingevuld]

Tillor adapts the notation to the kind of field.

**In plain text** (titles, descriptions, subtasks):

- Dates are in your organisation's time zone, for example `05-10-2026`. If the time is not exactly midnight, a time is added too, such as `05-10-2026 14:30`
- An empty field gives an empty text
- A variable that Tillor does not know stays as you wrote it, for example `{occupation.terain.name}`. A typing mistake is then spotted at once in the task or the message
- If a linked record is not there, the variable stays empty. An occupation without a reservation therefore gives nothing for `{occupation.reservation.displayId}`, and an event caused by the system gives nothing for `{triggeredBy.name}`. If you want different text in that case, put an **If / else** with **is empty** in front of it

**In JSON** (the **Payload** of a webhook and the **Body** of an API request):

- Text is filled in safely. Quotation marks, new lines and other special characters in the value cannot break the JSON
- Numbers and yes/no values come without quotation marks, so do not put any around them. Text you do put between quotation marks
- Dates go through as an international date and time, such as `2026-10-05T08:00:00.000Z`, so that the receiving system can handle them properly

```json
{
  "reservation": "{reservation.displayId}",
  "adults": {reservation.numberOfAdults}
}
```

If the JSON is not valid after filling in, for example because a number is empty, the run stops with an error message.

**In a path or URL** (with an API request):

- Values are converted so that they fit in an address. A name with a space therefore does not give a broken address
- Dates go as an international date and time here too
- What you type yourself stays as you type it. If you want a space in a search term, type `%20` yourself

## Shifting a date [#een-datum-verschuiven]

A shift may follow a date variable: `{reservation.checkOut + 1 day}`, `{today - 2 weeks}`, `{invoice.dueDate + 3 hours|date}`. The units are `minutes`, `hours`, `days`, `weeks` and `months` (the singular is fine too). Days and weeks are fixed lengths, so that a validity period stays equally long across summer and winter time; months follow the calendar, so 31 January plus a month is 28 or 29 February. On a value that is not a date the shift does nothing, and a unit that does not exist is an error on the step. Date fields such as **Valid until** accept the same notation.

## Formatting a value [#een-waarde-opmaken]

Put a `|` and a format after the variable, for example `{invoice.amountOutstanding|currency}`. Without a format an amount appears plain, such as `1295.3`. With `|currency` that becomes `€ 1.295,30`.

| Format | Example | Result |
|--------|-----------|-----------|
| `currency` | `{invoice.amountOutstanding\|currency}` | `€ 1.295,30` |
| `currency:USD` | `{invoice.amountOutstanding\|currency:USD}` | `US$ 1.295,30` |
| `number` | `{invoice.amountOutstanding\|number}` | `1.295,3` |
| `number:2` | `{invoice.amountOutstanding\|number:2}` | `1.295,30` (fixed number of decimals) |
| `date` | `{invoice.dueDate\|date}` | `30-06-2026` |
| `datetime` | `{invoice.createdAt\|datetime}` | `01-06-2026 16:04` |
| `time` | `{invoice.createdAt\|time}` | `16:04` |
| `upper` / `lower` | `{customer.lastName\|upper}` | `VAN DEN BROECKE` |

- Numbers and amounts are always in Belgian notation: a full stop for thousands and a comma for decimals
- Dates and times are in your organisation's time zone
- If the format cannot read the value, for example `|currency` on text, the value simply appears without formatting
- A format that Tillor does not know stays as you wrote it, and the editor shows a message about it
- In JSON and in a URL the formatted value is filled in as text. So put quotation marks around it in JSON

## Using an API response [#een-api-antwoord-gebruiken]

After an [API request](/automatiseringen/acties/integraties#api-verzoek) you can use fields from the response with `{response.data.…}`. The response to a search for tasks looks like this, for example:

```json
{
  "items": [
    { "id": "task_1", "priority": "LOW" }
  ]
}
```

Then `{response.data.items.0.id}` gives the id of the first task (the first in a list is number 0) and `{response.data.items.0.priority}` its priority.

Tillor can only offer the fields of a response as a variable if it knows what the response looks like. That can be done in two ways:

- Let the automation run for real once. Tillor then uses the response of the last run
- Paste a sample into the **Test run** tab, in the **Sample API response** field. That field appears as soon as the flow contains an **API request**. Below it are **Fields in this response**. Click a field to have it copied, including curly braces

After that the fields are in the list behind the **Variable** button and in the list under **Field** of a **Switch**.

If you type a path under `response.data` yourself, it is always accepted, even without a sample. Furthermore:

- `{response.body}` contains the first 4000 characters of the response. If the response is longer, the rest is cut off
- `{response.data}` is empty if the response is not JSON, or if the response is very large (more than 100,000 characters)
- For a search without a result, `{response.data.items.0.id}` does not exist. A **Switch** on such a field then goes via **Default**

<Callout type="info" title="A sample in the test">
In the **Test run** tab you also fill in the sample data of the event. That way you see in the test run which values Tillor would fill in. See [Testing and runs](/automatiseringen/testen-en-uitvoeringen).
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- As soon as the automation runs, Tillor replaces every variable with the real value. A variable that Tillor does not know stays as you wrote it.
- If a piece of data is empty, the spot stays empty. If you want different text then, put an **If / else** with **is empty** in front of it.

## Problems? [#problemen]

<Accordions>
<Accordion title="I see {occupation.terain.name} in my task">
A variable that Tillor does not know stays literally as it is. Usually there is a typing mistake. Choose the variable via the **Variable** button.
</Accordion>
<Accordion title="Tillor says a variable is not available at this step">
You are using a piece of data that does not exist yet at this point in the flow, for example from a step that comes later or from an exit you did not take. Put the step that provides the data earlier in the flow. As long as the message is there, you cannot enable the automation.
</Accordion>
<Accordion title="The JSON is not right after filling in">
A number that is empty makes the JSON invalid. You put text between quotation marks, numbers not. Check the fields with a test run.
</Accordion>
<Accordion title="I do not see the fields of an API response in the list">
Tillor does not yet know the shape of the response. Let the automation run for real once, or paste a sample into **Sample API response** on the **Test run** tab.
</Accordion>
</Accordions>


# Frequently asked questions (/en-GB/automatiseringen/veelgestelde-vragen)

## Who can use automations? [#wie-kan-automatiseringen-gebruiken]

Anyone with **View automations** sees the automations and their runs. Anyone with **Manage automations** can also create, change, enable and delete them. Administrators with **All permissions** can do everything. You give these permissions to the members of your organisation.

Be careful with **Manage automations**: an automation works with all the permissions of your organisation. Anyone who may build flows can therefore do anything through a flow. Give it only to people you trust with that. Anyone with neither permission does not see the menu item **Admin > Automations**.

## Why does my automation not start? [#waarom-start-mijn-automatisering-niet]

Go through these points.

1. **Is it on?** An automation whose switch is off (filter **Paused**) does not start. If there are issues, you could not enable it. See [Issues and enabling](/automatiseringen/problemen)
2. **Is it the right event?** A new reservation is `reservation:created`, a change is `reservation:updated`. Also check that the event really occurs with the action you take
3. **Is the filter holding it back?** Events that do not pass the filter under **Only when** leave no run behind. Use the **Test run** tab with the data of a real case to see which condition does not match. Pay attention to the values of choice fields: an invoice status is, for example, `BOOKED`
4. **Is Run once per record on?** Then the automation does not start again for an invoice or reservation for which it has already run. See [Run once per record](/automatiseringen/triggers#eén-keer-per-record-uitvoeren)
5. **Is it a schedule?** Then it starts in the minute in which it is due. A fixed time and a schedule use your organisation's time zone
6. **Did you just enable or change it?** It can take half a minute before everything notices
7. **Are many events coming in at once?** Then the runs are processed one by one and it can take a while before yours is up

If the automation does start but something goes wrong afterwards, look at the **Runs** tab to see what happened and where the run got stuck.

## Why does my schedule start late? [#waarom-start-mijn-schema-te-laat]

Schedules are checked every minute. An automation that starts on a date, an hour or according to a schedule begins in that minute. An event starts immediately.

## Can an automation keep starting itself? [#kan-een-automatisering-zichzelf-blijven-starten]

Not within one flow. If you connect an exit so that the flow would jump back to an earlier step, Tillor refuses that line. You cannot enable a flow with such a loop. If a run does reach a step it already did, it stops, instead of doing that step again.

Not via events either. What a step does happens as the user **Workflow**, and events that **Workflow** causes do not start automations. An automation that starts on `task:created` and does a **Create task** therefore does not start again on the task it made itself. That also applies between automations: one cannot start another.

If many events come in within a short time, for example because of a large mailing, every event starts a run. Tillor handles a few at a time. Nothing is lost, but it can take a while.

## What limits apply? [#welke-grenzen-gelden-er]

| What | Limit |
|---|---|
| Steps in one automation | 100 |
| Branches in a **Switch** | 8, besides **Default** |
| Connections from one exit | 1 step. If you connect again, the new line replaces the old one |
| Length of the name | 120 characters |
| Length of the description | 500 characters |
| Notes and containers on the canvas | 50 together |
| Options with **Ask for a decision** | 8 |
| Wait time of an API request | 15 seconds |
| The response in `{response.body}` | The first 4000 characters |
| The response in `{response.data}` | Up to 100,000 characters, larger is empty |
| Delay in seconds | Not exact, can be a few seconds later |
| Schedules | Checked every minute |
| Items in a **For each** | 100 at a time |
| Check with **Wait until** | At most every 5 minutes |
| Content of an incoming webhook | 100 KB |
| Runs on the **Runs** tab | The last 20 |

## Can several automations start on the same event? [#kunnen-er-meerdere-automatiseringen-op-dezelfde-gebeurtenis-starten]

Yes. Every enabled automation whose trigger and filter match starts its own run. Do not count on a fixed order.

## Can I have two things done at once after one exit? [#kan-ik-na-één-uitgang-twee-dingen-tegelijk-laten-doen]

No, an exit leads to one step. Put the actions one after the other, or make a second automation with the same trigger.

## What happens to running runs if I change something? [#wat-gebeurt-er-met-lopende-uitvoeringen-als-ik-iets-verander]

| What you do | What happens to runs |
|---|---|
| Change the flow and save | New runs use the new flow. Runs that are already busy or waiting finish with the flow as it was |
| Pause the automation | Runs that are waiting in a delay stop as soon as the wait time is over and get the status **Canceled**. What is already busy at that moment finishes. If you turn it back on before the wait time is over, the run simply continues |
| Delete the automation | The runs and the history are deleted. Waiting runs stop |

## What happens if a step fails? [#wat-gebeurt-er-als-een-stap-mislukt]

The run stops with the status **Failed** and the steps after it are not carried out. Whoever made the automation gets an email about the failed run, at most one per hour per automation. Tillor does not retry the step. With **Send webhook** and **API request** you can catch a failure with the **Failed** exit. With other actions you turn on **Continue when this step fails**: the step then gets an **Error** exit and the flow continues there. See [When a step fails](/automatiseringen/acties#als-een-stap-mislukt).

## Is anything really sent during a test? [#wordt-er-echt-iets-verstuurd-tijdens-een-test]

No. A test run sends nothing, creates nothing and changes nothing. See [Testing and runs](/automatiseringen/testen-en-uitvoeringen).

## Is my data stored safely? [#zijn-mijn-gegevens-veilig-opgeslagen]

Your flows and the run history, including headers with keys or tokens, are stored encrypted. For addresses on the internet, only `https` is allowed and internal addresses are refused.

## I am missing an event, condition or action [#ik-mis-een-gebeurtenis-voorwaarde-of-actie]

Use **Request a step** in the editor. See [Requesting a step or event](/automatiseringen/aan-de-slag#een-stap-of-gebeurtenis-aanvragen).

## Can I also manage automations from my own system? [#kan-ik-automatiseringen-ook-vanuit-mijn-eigen-systeem-beheren]

Yes, if your integration has all permissions. See [For developers](/ontwikkelaars/automatiseringen).

<Callout type="idea" title="Start small">
Start with one trigger and one action, let it run along for a few days and review the runs. Only then build it out with conditions and delays.
</Callout>


# Example: checking a rental caravan (/en-GB/automatiseringen/voorbeeld-nalopen)

This example builds a flow with a filter, **Find task**, **Set task priority**, an **If / else** and a task with subtasks. You do not need an API request for it.

In Tillor demo environments this flow is already there as a paused example under the name **Rental caravan check**. You can look at it there while you build along.

## What the flow does [#wat-de-flow-doet]

A guest leaves a static caravan. The caravan has to be checked before the next guest.

- If there is no open check task for that terrain yet, the flow creates one, with five subtasks and a deadline after 7 days. The task also goes to the colleague who ended the occupation
- If there is already an open check task, for example because the caravan became free twice shortly after each other, the flow does not create a second task. Instead the priority of the existing task goes up one step

```mermaid
flowchart TD
  A["Occupation ended<br/>static caravans only"] --> F{"Open check task?"}
  F -- Found --> P["Priority one step higher<br/>up to High"]
  F -- Not found --> B{"Ended by a colleague?"}
  B -- Yes --> C["Create check task<br/>with name of the colleague"]
  B -- No --> D["Create check task"]
```

The two task steps at the bottom are almost the same. Only the description differs: if the system ended the occupation, there is no colleague to mention.

## What you need [#wat-je-nodig-hebt]

- You have the permission **Manage automations**, or **All permissions**
- Your organisation has a terrain type for static caravans, in this example **Static caravan**
- Optional: a board and a column for the check tasks

## Building the flow [#de-flow-bouwen]

### 1. Creating an empty flow [#1-een-lege-flow-maken]

1. Go to **Admin > Automations** and click **New automation**
2. Choose **Start from scratch**
3. In the breadcrumb at the top, fill in the name **Rental caravan check**
4. Click on the canvas, next to the steps, and in the panel fill in under **Description** what the flow is for

### 2. Setting up the trigger [#2-de-trigger-instellen]

1. Click the trigger. Leave **Starts from** on **When something happens**
2. Under **Event** choose `occupation:ended`. Type *occupation* to search
3. Under **Step name** give the step the name *Occupation ended*

Now the flow starts for every occupation that ends. You want it only for static caravans:

1. Under **Only when** click **Add condition**
2. Click **Variable** and choose `occupation.terrain.terrainTypeId`
3. Leave the comparison on **is**
4. For the value, choose the terrain type **Static caravan**

<DocScreenshot src="/screenshots/automatiseringen/trigger-filter.png" alt="Trigger with the condition terrain type is Static caravan" />

### 3. Finding an open check task [#3-een-open-nalooptaak-zoeken]

1. Add a **Find task** step, connect the trigger to it and name it *Open check task?*
2. Under **Title** fill in `Check {occupation.terrain.name}`
3. Leave **Linked to the records of the event**, **Only tasks that are not completed** and **Skip subtasks** on

The step now looks for a main task that is not yet completed, is called exactly *Check* followed by the name of the terrain, and is linked to the same terrain, the same customer or the same reservation. Then the flow continues via **Found** or **Not found**.

### 4. Raising the priority [#4-de-prioriteit-verhogen]

1. Add a **Set task priority** step, name it *Raise priority* and connect the **Found** exit to it
2. Leave **Task** on `{foundTask.id}`
3. Leave **Change** on **One step higher** and **Raise up to** on **High**

### 5. Checking who ended the occupation [#5-nagaan-wie-de-bezetting-stopzette]

1. Add an **If / else** step, connect the **Not found** exit of *Open check task?* to it and name it *Ended by a colleague?*
2. Click **Add condition** and under **Variable** choose `triggeredBy.id`
3. Choose the comparison **is not empty**

`{triggeredBy.id}` is empty if the system ended the occupation, for example a scheduled task. Then the flow goes via **No**.

### 6. Creating the task [#6-de-taak-aanmaken]

Add a **Create task** step, name it *Create check task* and connect the **Yes** exit to it. Fill in the fields like this:

| Field | Value |
|---|---|
| **Title** | `Check {occupation.terrain.name}` |
| **Description** | `Generated automatically.`, an empty line, and `Occupation ended by @{triggeredBy.name}({triggeredBy.id})` |
| **Priority** | **Low** |
| **Due after** | 7 days |
| **Also assign whoever caused the event** | On |
| **Link to records** | On |
| **Subtasks** | Five lines: *Cleaning*, *Inventory*, *Internet + TV*, *QR code frame*, *Check for odd jobs* |

With `@{triggeredBy.name}({triggeredBy.id})` the colleague is mentioned in the description. If you want the task to go on a board, choose a board under **Add to board** and a column under **Column**. Whoever must always receive the task, you choose under **Assign to**.

Keep the title the same as in *Open check task?*. Otherwise the search step will not find the task the next time.

<DocScreenshot src="/screenshots/automatiseringen/task-step.png" alt="Create check task step with the settings in the panel" />

### 7. The task for the system [#7-de-taak-voor-het-systeem]

1. Click the step *Create check task* and then **Duplicate step**
2. Name the copy *Create check task (system)* and connect the **No** exit to it
3. Set the **Description** to only `Generated automatically.`

### 8. Testing and enabling [#8-testen-en-inschakelen]

1. Check that there is no issues button (such as **1 issue**) at the top of the panel
2. Open the **Test run** tab and click **Run test**. You see which path the flow takes and which title and description the task would get. Nothing is created
3. Turn the **Active** switch on

## Why two steps instead of one [#waarom-twee-stappen-in-plaats-van-één]

You can also use the **Find task** and **Set task priority** steps separately. If, for example, you want to do nothing when the task already exists, simply connect nothing to **Found**. If you want to give the existing task a comment or a different status, put another step after **Found**, such as **Set task status** with `{foundTask.id}`.

## What happens in practice [#wat-er-in-de-praktijk-gebeurt]

| Situation | What the flow does |
|---|---|
| No open check task for this terrain | Creates a new task with five subtasks |
| Open task with priority **Low** | Sets it to **Medium** |
| Open task with priority **Medium** | Sets it to **High** |
| Open task with priority **High** or **Urgent** | Leaves the priority as it is |
| Occupation on a different terrain type | Does not start |

<Callout type="info" title="What the task looks like in Tillor">
The task is in the name of [**Workflow**](/automatiseringen/workflow-gebruiker) and is linked to the terrain and the customer of the occupation, and to the reservation if there is one. Not every occupation has a reservation. The colleague who ended the occupation is on the task as the assigned person.
</Callout>


# Who runs an automation? (/en-GB/automatiseringen/workflow-gebruiker)

An automation does not work under your name. All steps are run by a fixed user of your organisation called **Workflow**.

## What you will notice [#wat-je-ervan-merkt]

- A task that an automation creates is recorded under the name **Workflow**
- A comment that an automation adds through an [API request](/automatiseringen/acties/integraties#api-verzoek) is also recorded under the name **Workflow**
- In the editor, as long as you have not selected a step, the panel on the right reminds you that steps are run as your organisation's **Workflow** user, never as yourself

This way it is always clear what a colleague did and what an automation did. Your name never appears on something you did not do yourself.

## What **Workflow** is [#wat-workflow-is]

- A system user, not a colleague. You cannot log in with it and it has no mailbox
- There is one per organisation. It exists only within your organisation and cannot do anything anywhere else
- It has all permissions within your organisation, like an administrator. That is also why only administrators can create and change automations
- It is not a member of the organisation, as a colleague is

<Callout type="warn" title="An automation can do a lot">
Because **Workflow** is allowed to do everything, an automation can also do everything the Tillor API allows. An **API request** can, for example, change or delete data. So keep your flows small and test them well.
</Callout>

## What **Workflow** is not allowed to do [#wat-workflow-niet-mag]

An automation cannot create, change, enable or delete automations, and cannot view their runs. An API request for that is refused. This way a flow cannot change itself or another flow.

## Event caused by **Workflow** [#gebeurtenis-veroorzaakt-door-workflow]

What **Workflow** does causes ordinary events, for example a new task. In the timeline and in webhooks, **Workflow** then appears as the cause. Such events do not start automations: a flow cannot start itself or another flow. A run that is waiting with **Wait for an event** does carry on with it: that cannot start a new flow, so it cannot cause a loop either. You can read more about this in [Frequently asked questions](/automatiseringen/veelgestelde-vragen#kan-een-automatisering-zichzelf-blijven-starten).

## Who you assign to [#wie-wijs-je-toe]

**Workflow** is never assigned a task itself and never receives a message from **Notify colleagues**. If you want a colleague to pick up the task, choose a colleague under **Assign to**, or tick **Also assign whoever caused the event**.


# Register a payment (/en-GB/betalingsverwerking/betaling-registreren)

You register a payment on a booked invoice with an outstanding balance. The payment screen is the same for all methods. Only the fields under **Payment method** differ.

<Steps>
<Step>
### Open the invoice [#open-de-factuur]
Go to <UIPath>Administration > Invoices</UIPath> or open the invoice from <UIPath>Customers > customer > Invoicing</UIPath>. The invoice must be booked and have an outstanding balance.

<DocScreenshot src="/screenshots/facturen/invoice-booked-actions.png" alt="Booked invoice - Make payment" />
</Step>
<Step>
### Click Make payment [#klik-op-maak-betaling]
The **New payment for** screen for the invoice opens. At the top are the invoice total and the outstanding amount.
</Step>
<Step>
### Choose the payment method [#kies-de-betaalmethode]
Under **Payment method**, choose how the payment comes in. Which options you see depends on the invoice and on what your organisation has set up.

- **Terminal** sends the request to a card terminal. See [Terminal](/betalingsverwerking/terminal).
- **Cash**, **Transfer** and possibly **Others** register money that came in outside Tillor. See [Cash and transfer](/betalingsverwerking/contant).
- **Internal Transfer** moves balance to another invoice of the same customer. See [Internal transfer](/betalingsverwerking/interne-overboeking).
- **SEPA Mandate** collects the amount using an active mandate of the customer. See [Collecting an invoice](/betalingsverwerking/incasso).
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in]
**Amount** defaults to the outstanding amount. Use the 25%, 50%, 75% and 100% buttons to quickly fill in a part, or type an amount yourself. The amount cannot be higher than the outstanding amount.
</Step>
<Step>
### Submit the payment [#voer-de-betaling-uit]
Click **Submit payment**.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

The outstanding amount and the payment status of the invoice are updated. The payment appears on the invoice under **Payments** and in <UIPath>Administration > Payments</UIPath>. How to find them is covered in [Finding payments](/betalingsverwerking/betalingen-bekijken).

Would the customer rather pay themselves? Then send the invoice with **Send notification**. See [Paying online](/betalingsverwerking/online).

## Problems? [#problemen]

<Accordions>
<Accordion title="I don't see a Make payment button">
The button only appears on a booked invoice with an outstanding balance. A draft invoice has to be booked first. A fully paid invoice no longer has a button.
</Accordion>
<Accordion title="SEPA Mandate is greyed out">
The customer has no active mandate whose maximum amount is high enough for this amount. For a credit note the method is not in the list. See [Collecting an invoice](/betalingsverwerking/incasso).
</Accordion>
<Accordion title="The Terminal method is missing">
Terminal only appears in the list if Mollie is connected and your organisation can receive card payments. See [Terminal](/betalingsverwerking/terminal).
</Accordion>
</Accordions>


# Finding payments (/en-GB/betalingsverwerking/betalingen-bekijken)

You can see payments in three places: on the invoice itself, in the overview of all payments and in the detail screen of a payment.

## View the payments of an invoice [#betalingen-van-een-factuur-bekijken]

Open the invoice and scroll to **Payments**. You only see the payments attached to this invoice.

<DocScreenshot src="/screenshots/facturen/invoice-payments.png" alt="Payments on the invoice" />

## Search all payments [#alle-betalingen-doorzoeken]

Go to <UIPath>Administration > Payments</UIPath>. Filter by date, payment method, status or customer, or search by customer name or invoice number.

<DocScreenshot src="/screenshots/betalingen/payments-list.png" alt="Payments overview - All payments" />

Through the action menu (three dots) on a payment you can, depending on the payment:

| Action | What it does |
|---|---|
| **Details** | Opens the detail screen |
| **Payment PDF** | Creates a proof of payment |
| **Sync** | Fetches the current status from Mollie. Only for Mollie payments that already exist at Mollie |
| **Skip delay** | Sends a scheduled direct debit to the bank now. See [Collecting an invoice](/betalingsverwerking/incasso) |
| **Unassign from invoice** | Removes the payment from the invoice |
| **Cancel** | Cancels a payment that has not been completed yet |
| **Delete** | Deletes the payment |

## Read the details of a payment [#de-details-van-een-betaling-lezen]

Click **Details** for the **Payment Details** screen. You see the amount, the status, the method, the invoice and a timeline.

- **Due date** appears on a pending SEPA direct debit. The status then shows <Status tone="warning">Expected</Status> with that date.
- **Send after** appears on a direct debit that Tillor has not yet sent to the bank.
- **Payment Report** shows the report the payment ends up in. As long as the payment is not yet in a report, the report number is shown with **(expected)** after it. For a Mollie payment it says **With the next Mollie payout**, because the report is only known at the payout.

You can read more about reports in [Payment reports](/boekhouden/betalingsrapporten).

## Status labels [#statuslabels]

| Status | Meaning |
|---|---|
| <Status tone="warning">Pending</Status> | The payment is still in progress |
| <Status tone="info">Authorized</Status> | Approved, not yet completed |
| <Status tone="success">Paid</Status> | Completed |
| <Status tone="error">Failed</Status> | Did not succeed |
| <Status>Canceled</Status> | Stopped before it was finished |
| <Status>Expired</Status> | The payment session ran out |
| <Status>Refunded</Status> and <Status>Partially Refunded</Status> | The amount has been returned in full or in part |
| <Status tone="warning">Refund Pending</Status> and <Status tone="warning">Partial Refund Pending</Status> | The refund has been created at Mollie, but the money has not reached the customer yet. The refunded amount already counts in the invoice balance. Once Mollie carries out the refund, the status becomes **Refunded** or **Partially Refunded** |
| <Status tone="error">Charged Back</Status> | The bank or card issuer has taken the amount back |

## Follow up outstanding amounts [#openstaande-bedragen-opvolgen]

Go to <UIPath>Administration > Invoices</UIPath>. The **Invoices with Open Balance** card shows booked invoices that have not yet been paid in full. In the tables, filter on payment status **Outstanding** and sort by due date.

<DocScreenshot src="/screenshots/facturen/invoice-open-balance.png" alt="Invoices with open balance" />

### Send a reminder [#een-aanmaning-versturen]

You send a reminder per invoice, not in bulk.

<Steps>
<Step>
### Open the invoice [#open-de-factuur]
Choose an invoice that is still outstanding.
</Step>
<Step>
### Send the reminder [#verstuur-de-aanmaning]
Click **Send notification** and choose **Send reminder**. Confirm the sending.
</Step>
</Steps>

The customer receives a reminder with a link to pay online. See [Paying online](/betalingsverwerking/online).

## Problems? [#problemen]

<Accordions>
<Accordion title="The status does not match Mollie">
Use **Sync** in the action menu of the payment. Tillor then fetches the current data. This helps especially if a notification from Mollie was missed.
</Accordion>
<Accordion title="I don't see Sync">
The action only appears for Mollie payments that already have a transaction at Mollie. For a direct debit that Tillor has not sent yet, there is nothing to fetch.
</Accordion>
</Accordions>


# Register cash and transfer payments (/en-GB/betalingsverwerking/contant)

With **Cash**, **Transfer** and possibly **Others** you record that a customer paid outside Tillor. Tillor then sends nothing. It updates the outstanding balance of the invoice.

- **Cash**: the customer pays in cash at the desk.
- **Transfer**: you received a bank transfer that was not automatically matched to the invoice.
- **Others**: for other payments with their own description, such as a cheque or an exchange. The method only appears if your organisation has turned it on.

## Register a payment [#een-betaling-registreren]

<Steps>
<Step>
### Open the payment screen [#open-het-betaalscherm]
Open a booked invoice with an outstanding balance and click **Make payment**.

<DocScreenshot src="/screenshots/betalingen/payment-dialog-cash.png" alt="Payment dialog - Cash" />
</Step>
<Step>
### Choose the method [#kies-de-methode]
Under **Payment method**, choose **Cash** or **Transfer**.
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in]
Type an amount or use the 25%, 50%, 75% and 100% buttons.
</Step>
<Step>
### Check the date received [#controleer-de-datum-van-ontvangst]
**Date received** defaults to today. Change it if the money came in on another day.
</Step>
<Step>
### Add a note if needed [#voeg-eventueel-een-opmerking-toe]
Under **Note** you can enter a reference number or note. For **Others**, a description is required.
</Step>
<Step>
### Submit the payment [#voer-de-betaling-uit]
Click **Submit payment**.
</Step>
</Steps>

<Callout type="idea" title="Date received">
The date determines which payment report the payment ends up in. If you register a payment from yesterday today, set the date to yesterday so the right report is topped up.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

The payment appears immediately on the invoice and in <UIPath>Administration > Payments</UIPath>. See [Finding payments](/betalingsverwerking/betalingen-bekijken).

For **Transfer** you can also have the customer receive an email with the tip to use the structured communication for future transfers. The **Send structured communication reminder** checkbox is in the payment screen. The checkbox is greyed out if the customer has no email address.

## Settings for manual payments [#instellingen-voor-handmatige-betalingen]

Under <UIPath>Support > Settings > Payments</UIPath> you will find these settings:

| Setting | What it does |
|---|---|
| **Show "Others" payment method** | Adds the **Others** method to the payment screen |
| **Cash payment maximum** | The highest cash amount per payment, 2999 euros by default |
| **Default: manual bank transfer reminder** | Turns the reminder checkbox on by default |
| **Cash payment maximum** | Highest amount you can register as a cash payment, in whole euros (default 2999) |

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor refuses my cash amount">
A cash payment cannot be higher than the **Cash payment maximum** under <UIPath>Support > Settings > Payments</UIPath> (2999 euros by default). Register the amount in parts, or choose another method.
</Accordion>
<Accordion title="I don't see the Others method">
The method is turned off. Turn on **Show "Others" payment method** under <UIPath>Support > Settings > Payments</UIPath>.
</Accordion>
<Accordion title="I don't see any manual methods">
Manual payments are not available for every invoice. The screen says so.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Register a payment" href="/betalingsverwerking/betaling-registreren" />
  <Card title="Terminal" href="/betalingsverwerking/terminal" />
</Cards>


# Payment groups (/en-GB/betalingsverwerking/groepen)

A payment group bundles several incoming payments under one name, so you can attach them to a booked invoice in one go. Handy if you only want to reconcile at the end of the day or of an activity.

Examples:

- **Closing a till shift**: all card payments of the day are in one group. You attach them to the daily revenue invoice.
- **Invoicing an activity**: participants pay online in advance. When booking, you attach the whole group to the invoice.
- **A reservation with deposit and balance**: deposit and final payment are in one group and are assigned in one go.

## The rules [#de-regels]

- A group has the status <Status tone="info">Open</Status> (not yet attached) or <Status tone="success">Assigned</Status> (already attached to an invoice).
- A group has no customer of its own. The customer follows from the invoice you attach the group to.
- You can only move the payments in a group together. You cannot attach an individual payment from a group to another invoice.
- You can only attach a group to a booked invoice. Draft invoices can still change or disappear.

## Attach a group to an invoice [#een-groep-aan-een-factuur-koppelen]

<Steps>
<Step>
### Open the payment groups [#open-de-betalingsgroepen]
Go to <UIPath>Administration > Payments</UIPath> and look under **Payment groups**. By default the list only shows open groups. Change the **Status** filter to also see assigned groups.

<DocScreenshot src="/screenshots/betalingen/payment-groups.png" alt="Payments overview - Payment groups" />
</Step>
<Step>
### Choose Assign [#kies-koppelen]
Open the action menu (three dots) on an open group and choose **Assign**.
</Step>
<Step>
### Choose the invoice [#kies-de-factuur]
Select the booked invoice the whole group should be attached to.
</Step>
<Step>
### Confirm [#bevestig]
Click **Assign** in the window. All payments in the group go to that invoice in one go, and the group gets the status <Status tone="success">Assigned</Status>.
</Step>
</Steps>

You can also do it from the invoice. There, choose **Assign payment** in the action menu, go to the **Payment groups** tab and click **Assign group**.

## What happens next? [#wat-gebeurt-er-daarna]

An assigned group appears on the invoice PDF as one line with the total of the group. You expand the individual payments in the payment overview of the invoice. You see the group itself again in the details of each payment in it.

If the group contains a Mollie payment that already exists at Mollie, **Sync** appears next to **Assign**. That action fetches the current data of all suitable payments in the group at once. This helps if you are unsure about the status or a notification was missed. You can remove an empty group with **Delete**.

## How do payments get into a group? [#hoe-komen-betalingen-in-een-groep]

Your till or activity system can pass a group name when it creates a Mollie payment. Tillor then creates a group itself, or uses an existing open group, and puts the payment in it. The fields for this are in [Mollie metadata](/ontwikkelaars/mollie-metadata#ingestie-hints-voor-betalingsgroepen).

## Problems? [#problemen]

<Accordions>
<Accordion title="I can't attach the group to my invoice">
The invoice is still a draft. Book it first, because only booked invoices can receive a group.
</Accordion>
<Accordion title="I want to put a payment from the group on another invoice">
That is not possible for a payment that is still in a group. Work at the level of the group.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Finding payments" href="/betalingsverwerking/betalingen-bekijken" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Mollie metadata" href="/ontwikkelaars/mollie-metadata" />
</Cards>


# Collect an invoice with a mandate (/en-GB/betalingsverwerking/incasso)

If a customer has an active mandate, Tillor can collect an invoice from their bank account. You choose how: you attach the mandate to the invoice so collection starts by itself after booking, or you start the collection manually with **Make payment**.

You request a mandate through [Having a SEPA mandate signed](/betalingsverwerking/mandaat). You cannot collect a credit note.

## Have an invoice collected automatically [#een-factuur-automatisch-laten-innen]

<Steps>
<Step>
### Open the invoice [#open-de-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open a draft or booked invoice of the customer.
</Step>
<Step>
### Choose the mandate [#kies-het-mandaat]
Under **Direct-debit mandate**, choose the customer's mandate. Only active mandates are in the list. Choose **No mandate** to remove the link again.

The field tells you what happens: Tillor immediately creates an outstanding payment, and the bank is charged two days after booking. Until then you can cancel the payment.
</Step>
<Step>
### Book the invoice [#boek-de-factuur]
After booking, the invoice shows **Collection is scheduled for** with the date. On that day Tillor sends the direct debit to the bank.
</Step>
</Steps>

If the invoice was already booked when you attached the mandate, the same two-day period applies from that moment. Once Tillor has sent the direct debit to the bank, you can no longer change the mandate on the invoice.

### The maximum amount of a mandate [#het-maximumbedrag-van-een-mandaat]

Every mandate has a maximum amount. You see it in the list of mandates as **max.** with an amount. If an invoice is higher, then:

- the mandate is greyed out in the list, with a message that the maximum is lower than the invoice amount;
- the invoice shows a message that the invoice amount exceeds the maximum of the mandate;
- Tillor cannot book an invoice with such a mandate attached.

Then choose a mandate with a higher maximum, or let the customer pay another way.

## Start a direct debit manually [#een-incasso-handmatig-starten]

<Steps>
<Step>
### Open the payment screen [#open-het-betaalscherm]
Open the booked invoice and click **Make payment**.

<DocScreenshot src="/screenshots/facturen/invoice-booked-actions.png" alt="Booked invoice - Make payment" />
</Step>
<Step>
### Choose SEPA Mandate [#kies-sepa-mandaat]
Under **Payment method**, choose **SEPA Mandate**. If it is greyed out, the customer has no active mandate that can cover the amount.
</Step>
<Step>
### Choose the mandate and the delay [#kies-het-mandaat-en-de-vertraging]
Select the **Mandate**. Tillor picks the first active mandate that can cover the amount. Under **Delay (days)** enter 0 to 7 days. With 0 the direct debit goes to the bank immediately, with a higher number Tillor waits that many days.
</Step>
<Step>
### Submit the payment [#voer-de-betaling-uit]
Click **Submit payment**.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

The payment appears on the invoice and in <UIPath>Administration > Payments</UIPath>.

- As long as the direct debit is waiting, the details show **Send after** with the date. Choose **Skip delay** in the action menu to send it to the bank now, or **Cancel** to stop it.
- After sending, the payment has the status <Status tone="warning">Pending</Status> with the **Due date**. A SEPA direct debit takes a few days. Then it becomes <Status tone="success">Paid</Status>, or <Status tone="error">Failed</Status> if the bank rejects the direct debit.
- In the accounting, a pending direct debit already counts as a payment in progress. If it fails or you cancel it, it disappears from the draft again. See [Payment reports](/boekhouden/betalingsrapporten).
- On the payment page the customer sees **Paid by direct debit** with the amount and the date, and no payment buttons. This way nobody pays twice. The invoice PDF and the invoice email state the amount and the collection date.

Tillor deducts the small first payment with which a customer confirmed their mandate from the next invoice.

## Collect utility invoices automatically [#nutsfacturen-automatisch-innen]

You can have consumption invoices for water, electricity and gas collected automatically with the customer's mandate.

- If the customer ticks **Also use this mandate to pay my utility bills (water, electricity, gas) automatically** when signing, Tillor sets up this mandate as soon as it is active. The checkbox is ticked by default.
- You can also choose the mandate yourself under <UIPath>Customers > customer > Invoicing</UIPath>, in the **Invoice Settings** card, under **Mandate**.
- In the list of mandates, the mandate for utilities is marked **Utility bills**.

A new consumption invoice then gets this mandate automatically as its **Direct-debit mandate**.

## Problems? [#problemen]

<Accordions>
<Accordion title="SEPA Mandate is greyed out under Make payment">
The customer has no mandate with the status <Status tone="success">Active</Status> whose maximum is high enough. Check the **Mandates** card under <UIPath>Customers > customer > Invoicing</UIPath>.
</Accordion>
<Accordion title="I can't book the invoice">
The attached mandate has a lower maximum than the invoice amount. Choose another mandate or remove the mandate from the invoice.
</Accordion>
<Accordion title="I can no longer change the mandate on the invoice">
Tillor has already sent the direct debit to the bank. Follow the payment in <UIPath>Administration > Payments</UIPath>.
</Accordion>
<Accordion title="The direct debit failed">
Open the payment for the reason. The invoice is open again. Choose **Make payment** for a new direct debit or another method, or send the customer a payment link with **Send notification**.
</Accordion>
<Accordion title="I still want to stop the direct debit">
As long as the payment under <UIPath>Administration > Payments</UIPath> still shows **Send after**, you can cancel it. If it has already been sent, that is no longer possible. You can revoke the mandate for the following invoices, see [Revoking a mandate](/betalingsverwerking/mandaat-beheren).
</Accordion>
</Accordions>

Automations can also collect: the step [Collect by direct debit](/automatiseringen/acties/facturen-en-betalingen#innen-via-domiciliëring).

## See also [#zie-ook]

<Cards>
  <Card title="Having a SEPA mandate signed" href="/betalingsverwerking/mandaat" />
  <Card title="Revoking or resending a mandate" href="/betalingsverwerking/mandaat-beheren" />
  <Card title="Finding payments" href="/betalingsverwerking/betalingen-bekijken" />
</Cards>


# Overview (/en-GB/betalingsverwerking)

A payment in Tillor usually belongs to a booked invoice. The customer can pay online themselves, you can register a payment at the desk, or Tillor collects the amount automatically through a SEPA mandate. On this page you see which method is for what.

<Callout type="info" title="Good to know">
- A payment belongs to a booked invoice. You cannot pay on a draft.
- A cash payment can be at most 2999 euros by default. You change that with **Cash payment maximum** under <UIPath>Support > Settings > Payments</UIPath>.
- Above 2500 euros, the payment page warns the customer that the bank or card may refuse the online payment. The customer then gets the IBAN and the structured communication to transfer the money.
- A direct debit with a mandate goes to the bank two days after booking. With **Make payment** you choose a delay of 0 to 7 days yourself. Until the direct debit leaves, you can cancel it.
- If an invoice is higher than the maximum of the mandate, you cannot collect it. If that mandate is on the invoice, you cannot book the invoice either.
- The signing link of a mandate works for 14 days. Tillor reminds the customer after 7 days, 2 days before it expires and on the last day.
- An internal transfer is only possible between two booked invoices of the same customer.
- Tillor cannot refund money to a customer. You arrange a refund outside Tillor, for example with a bank transfer.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

Every method ends in the same place: a payment on the invoice. From there it flows on to the payment report and your accounting.

```mermaid
flowchart LR
  F[Booked invoice] --> M{Payment method}
  M -- Online --> P[Payment]
  M -- Terminal --> P
  M -- Cash or transfer --> P
  M -- SEPA direct debit --> P
  M -- Internal transfer --> P
  P -- Status and balance --> F
  P -- Per day --> R[Payment report]
  R --> B[Accounting]
```

A direct debit first stays <Status tone="warning">Pending</Status>. The invoice then already shows as paid (pending). If the collection fails, the invoice is open again. Payment reports and the link with accounting software are covered in [Accounting](/boekhouden).

## Which method do you choose? [#welke-methode-kies-je]

| Method | When | How the customer pays | What Tillor books |
|---|---|---|---|
| [Paying online](/betalingsverwerking/online) | The customer pays themselves, at home or on the road | Through the link in the invoice email or text message, with iDEAL, Bancontact, credit card or another method | The payment as soon as the payment partner confirms it, even if the customer does nothing more |
| [Terminal](/betalingsverwerking/terminal) | The customer is at the desk | With card or phone on a Mollie card terminal | The payment as soon as the terminal completes it |
| [Cash and transfer](/betalingsverwerking/contant) | Money received outside Tillor | Cash at the desk or a bank transfer | The payment you register, with the date received |
| [SEPA mandate](/betalingsverwerking/incasso) | Recurring or large invoices, consumption | They don't. Tillor collects the amount from the bank account | A pending payment until the bank confirms the collection |
| [Internal transfer](/betalingsverwerking/interne-overboeking) | Moving balance between two invoices of the same customer | They don't. No money comes in | Two linked payments, one positive and one negative |

Online payments, card payments and direct debits go through Mollie. You register cash payments and transfers yourself.

<Cards>
  <Card title="Register a payment" href="/betalingsverwerking/betaling-registreren" icon={<ReceiptTextIcon />} description="The payment screen on a booked invoice" />
  <Card title="Finding payments" href="/betalingsverwerking/betalingen-bekijken" icon={<SearchIcon />} description="Per invoice, in the overview and in the details" />
  <Card title="Paying online" href="/betalingsverwerking/online" icon={<GlobeIcon />} description="The payment page the customer sees" />
  <Card title="Terminal" href="/betalingsverwerking/terminal" icon={<MonitorSmartphoneIcon />} description="Card payments at the desk" />
  <Card title="Cash and transfer" href="/betalingsverwerking/contant" icon={<BanknoteIcon />} description="Register payments outside Tillor" />
  <Card title="Internal transfer" href="/betalingsverwerking/interne-overboeking" icon={<ArrowLeftRightIcon />} description="Move balance between invoices" />
  <Card title="Having a SEPA mandate signed" href="/betalingsverwerking/mandaat" icon={<FileSignatureIcon />} description="Remotely or at reception" />
  <Card title="Collecting an invoice" href="/betalingsverwerking/incasso" icon={<LandmarkIcon />} description="Collect automatically with a mandate" />
  <Card title="Payment groups" href="/betalingsverwerking/groepen" icon={<LayersIcon />} description="Bundle payments and attach them in one go" />
  <Card title="Practical examples" href="/praktijk" icon={<ReceiptTextIcon />} description="Worked examples from practice" />
</Cards>

## Terms [#begrippen]

- **Payment**: a received or pending amount, with a method, a status and usually an invoice.
- **Mandate**: a customer's permission to collect invoices from their bank account. See [SEPA mandate](/betalingsverwerking/mandaat).
- **Payment group**: a bundle of payments that you later attach to an invoice in one go. See [Payment groups](/betalingsverwerking/groepen).
- **Payment report**: the daily overview of received payments for the accounting. See [Payment reports](/boekhouden/betalingsrapporten).
- **Internal transfer**: moving balance between two invoices of the same customer, without any money coming in.
- **Direct debit**: Tillor collects the amount from the customer's bank account, with their mandate.
- **Customer**: the customer the invoice belongs to. See [Customer](/begrippen#klant).


# Make an internal transfer (/en-GB/betalingsverwerking/interne-overboeking)

With **Internal Transfer** you move an amount from one booked invoice to another booked invoice of the same customer. No money comes in. Tillor creates a positive payment on the invoice you write off and a linked negative payment on the target invoice.

This is not a cash payment, card payment or bank transfer. Those methods are separate in the payment screen.

## Register an internal transfer [#een-interne-overboeking-registreren]

<Steps>
<Step>
### Open the payment screen [#open-het-betaalscherm]
Open the booked invoice with an outstanding balance and click **Make payment**.

<DocScreenshot src="/screenshots/betalingen/payment-dialog-internal-transfer.png" alt="Payment dialog - Internal transfer with target invoice dropdown open" />
</Step>
<Step>
### Choose Internal Transfer [#kies-interne-overboeking]
Under **Payment method**, choose **Internal Transfer**.
</Step>
<Step>
### Choose the target invoice [#kies-de-doelfactuur]
Under **Target invoice**, select the booked invoice the amount goes to. The list only shows booked invoices of the same customer.
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in]
Type an amount or use the 25%, 50%, 75% and 100% buttons.
</Step>
<Step>
### Submit the payment [#voer-de-betaling-uit]
If needed, fill in **Date received** and click **Submit payment**.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor creates two linked payments, **Internal transfer from** and **Internal transfer to**, each with the invoice number of the other invoice.
- The outstanding balance of both invoices is updated.
- If you delete one of the two payments, Tillor deletes the other one too.

## Internal transfer and accounting [#interne-overboeking-en-boekhouding]

- An internal transfer appears on the payment report of the day you register it. If you register it today, it immediately appears on today's [draft report](/boekhouden/betalingsrapporten#concept-en-definitief).
- It goes into the accounting export, together with the Mollie payments.
- Cash payments, bank transfers and bank accounts do not go into the accounting export.

## After reversing an invoice with Extend occupation [#na-het-omkeren-van-een-factuur-met-bezetting-verlengen]

With **Reverse invoice** you turn an invoice into a credit note. An internal transfer between those two invoices is only a settlement in the accounting. It does not extend or shorten the occupation a second time.

What that means for **Paid until**:

- On the original invoice, **Paid until** does not change.
- On the credit note, **Paid until** only moves back if the original invoice had already been paid with a real payment, such as cash, transfer or Mollie. If it was only settled with an internal transfer, **Paid until** stays the same.
- **Invoiced until** was already adjusted at booking.

## Problems? [#problemen]

<Accordions>
<Accordion title="The target invoice is not in the list">
Only booked invoices of the same customer appear. Book a draft invoice first, and do not choose the same invoice you are making the payment on.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Register a payment" href="/betalingsverwerking/betaling-registreren" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Bank accounts" href="/boekhouden/betalingsrapporten/betaalmethodes/ponto" />
</Cards>


# Revoke or resend a mandate (/en-GB/betalingsverwerking/mandaat-beheren)

All actions for a mandate are in the menu (three dots) at the end of the row on the **Mandates** card. You will find that card under <UIPath>Customers > customer > Invoicing</UIPath>. Which actions you see depends on the status.

| Status | Actions in the menu |
|---|---|
| <Status tone="info">Awaiting signature</Status> | **Show on the iPad**, **Send reminder**, **Resend signing link**, **Cancel request** |
| <Status>Link expired</Status> | **Resend signing link**, **Cancel request** |
| <Status tone="error">Activation failed</Status> | **Cancel request** |
| <Status tone="success">Active</Status> | **Open signed mandate**, **Revoke mandate** |
| <Status>Revoked</Status> | **Open signed mandate** |

**Show on the iPad** only appears if the Tillor app on a device of your organisation is online.

## Resend an open request [#een-openstaande-aanvraag-opnieuw-versturen]

<Steps>
<Step>
### Open the menu on the request [#open-het-menu-bij-de-aanvraag]
Find the request with the status <Status tone="info">Awaiting signature</Status> or <Status>Link expired</Status>.
</Step>
<Step>
### Choose the action [#kies-de-actie]
- **Send reminder** emails the customer again, with a new link. The end date does not change.
- **Resend signing link** emails a new link that works for another 14 days.

A link sent earlier no longer works after either action.
</Step>
</Steps>

Tillor shows **Reminder sent** or **Signing link sent again**. The customer receives an email. How the automatic reminders work is covered in [Having a SEPA mandate signed](/betalingsverwerking/mandaat#herinneringen-voor-het-tekenen).

## Cancel a request [#een-aanvraag-annuleren]

Choose **Cancel request** if the customer no longer needs to sign. The request gets the status <Status>Canceled</Status>. If it is on the tablet, it disappears there. After that you can start a new request.

## Revoke an active mandate [#een-actief-mandaat-intrekken]

Revoke a mandate if the customer may no longer be charged, for example after a move, a cancelled contract or at the customer's request.

<Callout type="warn" title="Revoking cannot be undone">
For automatic payment you will then need a new mandate, with a new signature from the customer.
</Callout>

<Steps>
<Step>
### Choose Revoke mandate [#kies-mandaat-intrekken]
Open the menu on the active mandate and choose **Revoke mandate**.
</Step>
<Step>
### Confirm [#bevestig]
In the **Revoke this mandate?** screen, click **Revoke**. Tillor shows **Mandate revoked**.
</Step>
</Steps>

What happens next:

- No more invoices are collected through this mandate. Direct debits that Tillor had not yet sent to the bank are cancelled.
- The status of the mandate becomes <Status>Revoked</Status>.
- The signed document is kept as proof, but moves to the archive. In the customer's documents you will find it under **Archived**, so the list only shows mandates that still apply.
- The customer receives an email saying the mandate has been revoked, with a copy of the signed document.

Mandates that were set up outside Tillor only show **Revoke mandate** in the menu.

## Problems? [#problemen]

<Accordions>
<Accordion title="I don't see Revoke mandate">
The action only appears for a mandate with the status <Status tone="success">Active</Status>. You cancel a request that has not been signed yet with **Cancel request**.
</Accordion>
<Accordion title="A direct debit was already on its way to the bank">
Revoking only cancels direct debits that Tillor had not yet sent to the bank. You follow a direct debit that is already on its way under <UIPath>Administration > Payments</UIPath>.
</Accordion>
<Accordion title="I want to use a different mandate for an invoice">
Choose the mandate under **Direct-debit mandate** on the invoice. See [Collecting an invoice](/betalingsverwerking/incasso).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Having a SEPA mandate signed" href="/betalingsverwerking/mandaat" />
  <Card title="Collecting an invoice" href="/betalingsverwerking/incasso" />
</Cards>


# Having a SEPA mandate signed (/en-GB/betalingsverwerking/mandaat)

With a SEPA mandate, a customer gives permission to collect invoices automatically from their bank account. The customer signs the mandate in Tillor itself. Tillor stores the signed document with the customer, and after that you can have invoices collected. That is covered in [Collecting an invoice](/betalingsverwerking/incasso).

Before you start:

- Mandates must be enabled for your organisation. If they are not, the **Create Mandate** button says you need to contact the administrator.
- The customer needs an email address.
- A customer can only have one open request at a time.

## Request a mandate [#een-mandaat-aanvragen]

<Steps>
<Step>
### Open the customer [#open-de-klant]
Go to <UIPath>Customers > customer > Invoicing</UIPath>. At the bottom is the **Mandates** card with all the customer's mandates and requests.
</Step>
<Step>
### Click Create Mandate [#klik-op-mandaat-aanmaken]
A menu opens with one or two choices. Choose how the customer signs.
</Step>
</Steps>

<Tabs items={["Remotely", "At reception"]}>
<Tab value="Remotely">
Choose **Send mandate invitation**. The customer receives an email with a link to the signing page, and Tillor shows **Mandate sent for signature to** the customer's email address.

The link works for 14 days, up to and including the last day. The customer does not have to enter an IBAN. They choose for themselves how to confirm the mandate.
</Tab>
<Tab value="At reception">
Choose **Sign on the reception iPad**. The mandate appears on the tablet at reception, and Tillor shows **Mandate is on the iPad for the customer to sign**.

This choice only appears in the menu if the Tillor app on a device of your organisation is online. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken). The customer signs with their finger on the tablet. The signed document records that it was signed at reception, and which colleague used the tablet.

Has the request already been sent and do you still want to show it on the tablet? Open the menu on the request and choose **Show on the iPad**.
</Tab>
</Tabs>

## What does the customer do? [#wat-doet-de-klant]

The customer goes through a number of screens. On the tablet these are the same screens, with a few differences listed below.

<Steps>
<Step>
### View the mandate [#het-mandaat-bekijken]
The **Sign your SEPA mandate for** your organisation page shows who the creditor is, for whom they collect and what kind of payment it is. The customer taps **Sign mandate**.
</Step>
<Step>
### Accept the text [#de-tekst-accepteren]
The customer reads the summary or, via **Read the full mandate text**, the whole text, and ticks that they agree.

Below that is a second checkbox to also use the mandate for utility bills (water, electricity, gas). That checkbox is ticked by default. See [Collecting an invoice](/betalingsverwerking/incasso#nutsfacturen-automatisch-innen).
</Step>
<Step>
### Sign [#tekenen]
The customer signs with a finger or mouse.
</Step>
<Step>
### Choose the confirmation [#de-bevestiging-kiezen]
Under **How would you like to authorise?** the customer chooses between two ways to confirm.

- **A small first payment** with their own bank or card, for example through iDEAL, Bancontact, credit card or Apple Pay. The amount is between 0 and 1 euro, depending on the method. This way the bank confirms that the account is the customer's, and the customer does not have to type in an IBAN. Tillor deducts the amount from the next invoice.
- **Bank account (SEPA)**: the customer enters their IBAN, confirms that the account is theirs and enters a six-digit code. That code arrives by text message on the customer's phone number, or by email if no number is known.
</Step>
</Steps>

On the tablet the IBAN route works the same way: the code goes by text message to the customer's phone. If the customer chooses the first payment, the tablet shows a QR code that the customer scans with their phone to pay.

## What happens next? [#wat-gebeurt-er-daarna]

- The mandate appears in the list with the status <Status tone="warning">Signed, activating</Status>, or <Status tone="warning">Awaiting first payment</Status> if the customer chose the small payment.
- As soon as the mandate is valid at the payment partner, the status becomes <Status tone="success">Active</Status>. The customer receives a copy of the signed mandate by email.
- Tillor stores the signed document with the customer's documents. You open it through the menu on the mandate with **Open signed mandate**. The document is sealed and carries a timestamp, so a later change in a PDF reader is visible. See [Seal and timestamp](/handtekeningen/bewijs-en-geldigheid#zegel-en-tijdstempel).
- If the customer's window was closed before the first payment was complete, the request stays open. The customer can try again through the same link or switch to their IBAN.

## Statuses [#statussen]

| Status | Meaning |
|---|---|
| <Status tone="info">Awaiting signature</Status> | The customer has not signed yet |
| <Status tone="warning">Signed, activating</Status> | Signed with IBAN, Tillor is creating the mandate |
| <Status tone="warning">Awaiting first payment</Status> | Signed, the small payment still has to succeed |
| <Status tone="success">Active</Status> | You can use the mandate for direct debit |
| <Status tone="error">Activation failed</Status> | The payment partner refused the mandate. Tillor tries again later |
| <Status>Link expired</Status> | The customer did not sign within 14 days |
| <Status>Canceled</Status> | You canceled the request |
| <Status>Revoked</Status> | The active mandate has been revoked |

Mandates that were set up outside Tillor show the statuses <Status tone="warning">Pending</Status>, <Status tone="success">Active</Status>, <Status tone="error">Inactive</Status> and <Status>Canceled</Status>. You can only use an active mandate for direct debit.

## Reminders before signing [#herinneringen-voor-het-tekenen]

Tillor sends the customer reminders by email on its own while the request is open: when 7 days remain, two days before it expires and on the last day. Every reminder contains a fresh signing link.

Do you want to give the customer a nudge yourself? In the menu on the request, choose **Send reminder**. The end date then stays the same. If the link has expired, or you want to give another 14 days, choose **Resend signing link**. You can read more about these actions in [Revoking or resending a mandate](/betalingsverwerking/mandaat-beheren).

Do you want an automation to react when a request expires? For that there is the trigger **Mandate request expired**, see [Automations](/automatiseringen).

## Problems? [#problemen]

<Accordions>
<Accordion title="The Create Mandate button is greyed out">
Hover over the button for the reason. Usually the customer has no email address, or mandates are not enabled for your organisation. Add an email address to the customer or ask your administrator to turn mandates on.
</Accordion>
<Accordion title="Tillor says a mandate is already awaiting signature">
Only one request can be open per customer at a time. Resend the existing request or cancel it, and then create a new one.
</Accordion>
<Accordion title="The option to sign at reception is missing">
The option only appears if the Tillor app on a device of your organisation recently had contact with Tillor. Open the app on the tablet, wait a moment and try again.
</Accordion>
<Accordion title="The customer does not receive the text message code">
The code goes to the phone number on the customer profile. Check that it is correct. If the customer has no number, the code comes by email. The customer can ask for a new code.
</Accordion>
<Accordion title="The customer sees that the link has expired">
The customer sees **This signing link has expired**. On the request, choose **Resend signing link**.
</Accordion>
<Accordion title="The status stays Activation failed">
The payment partner has refused the mandate. Tillor automatically tries again later. If it keeps failing, cancel the request with **Cancel request** and ask the customer to sign again, possibly with a different confirmation.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Collecting an invoice" href="/betalingsverwerking/incasso" />
  <Card title="Revoking or resending a mandate" href="/betalingsverwerking/mandaat-beheren" />
  <Card title="Payment methods" href="/betalingsverwerking" />
</Cards>


# Letting a customer pay online (/en-GB/betalingsverwerking/online)

Paying online goes through the personal payment page of an invoice. The customer opens the page, chooses a payment method and completes the payment at their bank or card issuer. Tillor works with [Mollie](https://www.mollie.com) for this, so Mollie must be connected.

There is no separate Send payment link button. You share the page with a notification or with the personal URL of the invoice.

Before you start:

- The invoice is booked and an amount is outstanding. Otherwise the customer has nothing to pay.
- Mollie is connected. Without methods from Mollie, the customer only sees a pay button, see [Problems?](#problemen).
- The customer has an email address or phone number, or you share the link yourself.

## Send the payment link to the customer [#de-betaallink-naar-de-klant-sturen]

<Steps>
<Step>
### Book the invoice [#boek-de-factuur]
Paying online is only possible on a booked invoice with an outstanding balance.
</Step>
<Step>
### Send a notification [#verstuur-een-notificatie]
Click **Send notification** and choose a channel, such as email or SMS. The customer receives a message with the **View and pay online** button.
</Step>
</Steps>

Would you rather share it yourself? Open the action menu (three dots) on the invoice and choose **Personal URL**. Tillor copies the link to your clipboard. You send a reminder with the same link with **Send reminder**, see [Finding payments](/betalingsverwerking/betalingen-bekijken#een-aanmaning-versturen). Does the customer want to pay only part of it? Then create a [link for a part payment](/facturen/betalingen-registreren#een-link-voor-een-deelbetaling-maken).

## What does the customer see? [#wat-ziet-de-klant]

The customer opens the **Your invoice from** your organisation page. It shows the amount to pay, an overview of the invoice lines and a button to view the invoice. From that screen the customer continues in three steps.

<Steps>
<Step>
### Pay [#betaal]
The customer taps **Pay** with the amount. If there is an Apple Pay button, the customer can pay with it directly.
</Step>
<Step>
### Choose a method [#kies-een-methode]
Under **How would you like to pay?** are the available methods, such as iDEAL, Bancontact and credit card. The order comes from Mollie and adapts to the customer's language. These rules apply:

- The method the customer used last time on that device is shown with **Last used**.
- For French-speaking customers, Pay By Bank is at the top with **Often the best fit**.
- If a method has a disruption at Mollie, a warning is shown with it, for example that the method is partly unavailable or under maintenance. The customer can still try the method, but the message says it may not work. The text of the disruption comes from Mollie.
</Step>
<Step>
### Complete the payment [#rond-de-betaling-af]
What happens next depends on the method and the device. See below.
</Step>
</Steps>

### Completing on a computer or phone [#afronden-op-computer-of-telefoon]

<Tabs items={["On a computer", "On a phone"]}>
<Tab value="On a computer">
For iDEAL and Bancontact, Tillor shows a QR code under **Scan to pay with** the chosen method. The customer opens the bank app on their phone and scans the code. The page continues by itself as soon as the payment is in. If the customer would rather pay on the computer, they can do so with **Pay in your browser**.
</Tab>
<Tab value="On a phone">
For Bancontact, Tillor shows the **Pay with the Bancontact app** button. The customer completes the payment in the app and then returns to the page. With **Pay in your browser** the customer can also pay in the browser on the phone.
</Tab>
</Tabs>

For other methods, such as credit card, Tillor sends the customer on to the payment partner's payment page and then brings them back. If the redirect does not happen by itself, there is a link to continue.

### If it does not work [#als-het-niet-lukt]

- **Choose another method** takes the customer back to the list.
- **Start over** starts a new payment with the same method. Handy if the customer cancelled in the bank app or nothing happened.
- For a failed, canceled or expired payment, the page reports the outcome and the customer can choose another method.

## What else the page can show [#wat-de-pagina-nog-meer-kan-tonen]

| Situation | What the customer sees |
|---|---|
| The invoice is paid | **Paid in full** with the amount received, and a confirmation by email |
| The bank has started a transfer | **Confirming your payment**. With Pay By Bank this usually takes a few seconds and at most a few working days |
| A SEPA direct debit is scheduled | **Paid by direct debit** with the amount and the date. The customer does not have to do anything. Payment options are not shown, so nobody pays twice |
| The amount is higher than 2,500 euros | A warning that the bank or card may refuse the online payment because of limits, with the IBAN and the structured communication to transfer the money |
| Paying online is not possible for this invoice | **Pay by bank transfer** with the bank details |

## What happens next? [#wat-gebeurt-er-daarna]

The personal link has no expiry date. So the customer can still open it later. As soon as Mollie confirms the payment, it appears on the invoice and in <UIPath>Administration > Payments</UIPath>. The invoice goes to <Status tone="success">Paid</Status> when the full amount is in. You do not have to register anything yourself. See [Finding payments](/betalingsverwerking/betalingen-bekijken) for statuses.

## Problems? [#problemen]

<Accordions>
<Accordion title="The customer sees no payment methods">
Mollie is then not passing on any methods. The customer only sees the pay button and goes directly to Mollie's payment page with it. If that stays so, check the connection with Mollie.
</Accordion>
<Accordion title="The customer has paid, but the invoice is still open">
Open the payment via <UIPath>Administration > Payments</UIPath> and use **Sync**. With Pay By Bank, confirmation can take a few working days.
</Accordion>
<Accordion title="The customer gets a message about a disruption with a method">
Mollie reports that the method is having problems. The customer can choose another method or try again later.
</Accordion>
</Accordions>

Are you integrating your own system with Mollie payments? See [Mollie metadata](/ontwikkelaars/mollie-metadata).

## See also [#zie-ook]

<Cards>
  <Card title="Finding payments" href="/betalingsverwerking/betalingen-bekijken" />
  <Card title="SEPA mandate" href="/betalingsverwerking/mandaat" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
</Cards>


# Paying with a card terminal (/en-GB/betalingsverwerking/terminal)

With the **Terminal** payment method you send the outstanding amount of an invoice to a card terminal at the desk. The customer pays by card or phone, and Tillor records the payment as soon as the terminal completes it.

Tillor is the exclusive [Mollie](https://www.mollie.com) Tech Partner for card payments. Tillor supplies the Mollie terminals and sets up Mollie Connect, the device and the invoice link together with you. Questions about card payments at the desk therefore come to Tillor.

<Callout type="info" title="Mollie terminals only">
Tillor does not connect Worldline, CCV or other card machines. If you already have such a terminal, we will supply you with a Mollie device. That way online payments, card payments and the [payment report](/boekhouden/betalingsrapporten) stay one chain.
</Callout>

## Starting a card payment [#een-pinbetaling-starten]

<Steps>
<Step>
### Open the payment screen [#open-het-betaalscherm]
Open a booked invoice with an outstanding balance and click **Make payment**.

<DocScreenshot src="/screenshots/betalingen/payment-dialog-terminal.png" alt="Payment dialog with the Terminal payment method selected" />
</Step>
<Step>
### Choose Terminal [#kies-terminal]
Under **Payment method**, choose **Terminal**.
</Step>
<Step>
### Choose the terminal [#kies-de-terminal]
Select the terminal at your desk. Tillor only shows terminals that are available at that moment. If you only have one, it is already selected.
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in]
Type an amount or use the 25%, 50%, 75% and 100% buttons. A partial amount is handy for a deposit, or when the customer pays part in cash and part by card.
</Step>
<Step>
### Send the payment [#stuur-de-betaling]
Click **Submit payment**. The **Processing payment** screen appears while Tillor sends the request to the terminal.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

The screen follows the payment live. The customer pays on the terminal, and the screen goes from **Payment in progress** to **Payment successful**. It closes by itself after a few seconds, and the outstanding balance of the invoice is updated.

While the terminal is waiting, you can tick two boxes:

- **Print A4 when paid** puts the invoice PDF in the queue of the A4 printer as soon as the payment succeeds. The option is greyed out if no connector is online.
- **Mail after payment** emails the invoice to the customer as soon as the payment succeeds. The option is greyed out if the customer has no email address.

If the payment fails or expires, you get the message **Payment failed** or **Payment expired**. Click **Resend to terminal** to try again.

## Setting the default terminal [#de-standaardterminal-instellen]

Tillor activates the card device with your Mollie account. After Mollie has been connected, Tillor picks the terminal itself if there is exactly one active terminal. To choose a different one, go to <UIPath>Settings > Integrations</UIPath> under Mollie, in the **Default terminal** field (next to the **Primary profile**). Tillor then suggests that terminal for a card payment.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Terminal under Payment method">
The method only appears once Mollie is connected and a terminal belongs to your account. Check the connection under <UIPath>Settings > Integrations</UIPath>.
</Accordion>
<Accordion title="The terminal is missing from the list">
Tillor only shows terminals that are online and active. Check that the terminal is switched on and connected, and try again.
</Accordion>
<Accordion title="An old payment is still in progress">
After a new attempt, an old payment with the status <Status tone="warning">Pending</Status> can remain. Cancel it via <UIPath>Administration > Payments</UIPath> with **Cancel** in the action menu, so the invoice is correct.
</Accordion>
<Accordion title="A fault or an extra desk">
Email **support@tillor.eu**.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Registering a payment" href="/betalingsverwerking/betaling-registreren" />
  <Card title="Payment groups" href="/betalingsverwerking/groepen" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
</Cards>


# Occupations (/en-GB/bezettingen)

An occupation records that a customer is using a certain terrain (a camping pitch, a power post and the like). While the occupation runs, Tillor automatically allocates the consumption of the meters on that terrain to the customer. You manage occupations on the customer profile. Start with [Creating an occupation](#een-bezetting-aanmaken).

<Callout type="info" title="Good to know">
- A terrain can only be occupied by one customer at a time. Terrains with an active occupation do not appear in the selection list.
- **Paid until** only accepts today or a later date.
- You cannot change the terrain of an occupation afterwards. If a customer moves, end the occupation and create a new one.
- Deleting an occupation cannot be undone, but the consumption up to the end date is kept and can still be invoiced.
- With **Extend occupation (invoice)** the draft invoice gets a due date of 14 days after it is created.
- Only the fields **Type**, **Rent frequency** and **Price** are informational. They do not automatically drive meter registration or invoicing.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

An occupation connects three things: the customer, the terrain and the meters on that terrain. That is how Tillor knows in whose name the consumption goes.

```mermaid
flowchart LR
  K[Klant] --> B[Bezetting]
  B --> T[Terrein]
  T --> M[Meters op het terrein]
  M --> V[Verbruiksperiode van de klant]
  V --> F[Factuur]
  B -->|Bezetting verlengen| F
```

When you create an occupation, Tillor notes the start meter readings; when you end it, the end meter readings. The consumption in between belongs to the customer. A new occupation on the same terrain starts a new period.

## Viewing occupations [#bezettingen-bekijken]

Open a customer profile via <UIPath>Customers > Overview</UIPath> and go to the **Occupations** card on the **Overview** tab.

<DocScreenshot src="/screenshots/bezettingen/customer-occupations.png" alt="Occupations on a customer profile" />

- For each occupation the table shows the **Terrain**, **Type**, **Rent frequency**, **Price**, **Status** and **Paid until**, with a relative indication such as "in 12 days".
- Next to **Paid until** there is an info icon with **Invoiced until** in a tooltip, if that date has been filled in or is equal to **Paid until**.
- With **Filter occupations...** you search by terrain name.
- Actions per occupation (edit, extend, delete) are in the three-dot menu at the end of the row.

## Creating an occupation [#een-bezetting-aanmaken]

Before you start:

- The terrain must be free. If it is not in the list, it is already occupied. See Problems at the bottom.
- If the terrain has meters, have the start meter readings at hand. If you enter nothing, Tillor uses the last known reading.

<Steps>
<Step>
### Open the customer profile [#open-het-klantprofiel]
Go to <UIPath>Customers > Overview</UIPath>, open the customer and go to the **Occupations** card.
</Step>
<Step>
### Click Create occupation [#klik-op-bezetting-aanmaken]
You will find the button in the toolbar of the table. A dialog opens.
</Step>
<Step>
### Fill in the details [#vul-de-gegevens-in]
Only **Terrain** is required. The rest is optional.

- **Terrain**: choose via **Select a terrain**. Only available terrains are in the list. If no terrain is available at all, you see **No available terrains found.**
- **Paid until (optional)**: until when the customer has paid in advance. You choose today or later.
- **Invoiced until (optional)**: leave empty to follow the same date as **Paid until**, or choose your own date.
- **Type**: **Own accommodation** (default) or **Rental caravan**.
- **Rent frequency (optional)**: one of the options your organisation has set up, each with a start month and a number of months (for example starting in January, 6 months). Choose **No frequency** if you do not want to record one.
- **Description (optional)**: an explanation, for example rate agreements.
- **Price**: the occupation takes over the price of the terrain. With **Override inherited terrain price** you enter your own price.
- **Start meter readings (optional)**: appears as soon as the terrain has meters. If it has no meters, you see **No meters linked**.

<DocScreenshot src="/screenshots/bezettingen/customer-occupations-actions-menu.png" alt="Action menu of an occupation with Edit, Extend and Delete" />
</Step>
<Step>
### Confirm [#bevestig]
Click **Create occupation** to save.
</Step>
</Steps>

### Entering meter readings [#meterstanden-invullen]

<Tabs items={["Manual meter", "Automatic meter"]}>
<Tab value="Manual meter">
Type the reading yourself via the **Manual** tab. The field shows the last known reading as an example. If there are earlier readings, you can also pick an existing reading via **Select**.
</Tab>
<Tab value="Automatic meter">
A meter that sends readings by itself does not allow manual entry. Choose an existing reading via **Select a meter reading**.
</Tab>
</Tabs>

If you enter a reading that is lower than the previous saved reading, Tillor shows a warning. You can still confirm the lower value or adjust the entry.

### What happens next? [#wat-gebeurt-er-daarna]

- The occupation is active immediately and appears in the table on the customer profile.
- For every meter on the terrain, Tillor starts a consumption period for this customer. New meter readings count as the customer's consumption from now on.
- The terrain is no longer available for another occupation.

## Editing an occupation [#een-bezetting-bewerken]

<Steps>
<Step>
### Open the menu of the occupation [#open-het-menu-van-de-bezetting]
Click the three-dot menu next to the occupation and choose **Edit**.
</Step>
<Step>
### Adjust the fields [#pas-de-velden-aan]
You can change **Type**, **Rent frequency**, **Description**, **Paid until**, **Invoiced until** and **Price**. **Terrain** is read-only. If your organisation has [custom fields](/eigen-velden) for occupations, they appear at the bottom of the dialog.

<DocScreenshot src="/screenshots/bezettingen/customer-occupations-edit-dialog.png" alt="Edit occupation dialog" />
</Step>
<Step>
### Save [#sla-op]
Click **Save changes**. The change appears with a before/after overview on the customer's **Events** tab.
</Step>
</Steps>

## Ending an occupation [#een-bezetting-beëindigen]

Ending removes the link between customer and terrain. The terrain then becomes available again.

<Steps>
<Step>
### Choose Delete [#kies-verwijderen]
Click the three-dot menu next to the occupation and choose **Delete**. The **Delete occupation** window opens.
</Step>
<Step>
### Choose the date and the end meter readings [#kies-de-datum-en-de-eindmeterstanden]
If the terrain has meters, you can fill in **End meter readings (optional)**. First choose under **Date** the day on which the occupation ends (today or earlier). A field for the end reading then appears per meter. For a manual meter you enter it via **Manual** or pick it via **Select**. An automatic meter always asks for an existing reading via **Select a meter reading**.
</Step>
<Step>
### Confirm [#bevestig-1]
Click **Delete**. This cannot be undone.
</Step>
</Steps>

### What happens next? [#wat-gebeurt-er-daarna-1]

- Tillor closes the customer's open consumption periods. The consumption up to the end date is kept and can still be invoiced.
- The terrain is available again for a new occupation.
- The occupation disappears from the table.

## Invoicing: extending an occupation [#facturatie-bezetting-verlengen]

With **Extend occupation (invoice)** you create a draft invoice for the next period of an occupation, for example the annual pitch fee. You can do this for one occupation or for all of the customer's occupations at once.

Before you start: at least one product must exist with the action **Extend occupation period** (often a pitch fee). See [Products](/producten).

<Steps>
<Step>
### Start the action [#start-de-actie]
<Tabs items={["One occupation", "All occupations"]}>
<Tab value="One occupation">
Open the three-dot menu next to the occupation and choose **Extend occupation (invoice)**.
</Tab>
<Tab value="All occupations">
Click **Extend all** in the toolbar. All occupations go on one draft invoice, with one main line per occupation.
</Tab>
</Tabs>
</Step>
<Step>
### Choose whether to invoice consumption as well [#kies-of-je-verbruik-meefactureert]
Tick **Invoice outstanding consumption for this terrain** (with **Extend all**: **Invoice outstanding consumption (all terrains)**) if you also want to invoice outstanding consumption on the same draft invoice. If nothing is outstanding on the meters concerned, only the lines for extending the occupation remain.
</Step>
<Step>
### Create the draft invoice [#maak-de-conceptfactuur]
Click **Create draft invoice**. Tillor uses the first product with the action **Extend occupation period** (alphabetically by name) and builds the lines for you. Then complete the period on the invoice and book it when you are ready.
</Step>
</Steps>

### What happens next? [#wat-gebeurt-er-daarna-2]

- A draft invoice is ready for the customer, with the message **Ready** and a description of what was created.
- If you book the invoice, Tillor sets **Invoiced until** to the end moment of the line.
- After payment, Tillor updates **Paid until**. **Invoiced until** only moves forward if it was still before that end moment.

<Callout type="warn" title="Take care with an existing draft">
If there is already a draft invoice that extends this terrain, Tillor shows **Check before continuing**. A second draft can give duplicate lines or skip a period. Open the existing draft with **Open draft ...**, or choose **Create draft anyway**.
</Callout>

## Paid until, type, rent frequency and price [#betaald-tot-type-huurfrequentie-en-prijs]

| Field | Meaning |
|---|---|
| **Paid until** | Until when the customer has paid in advance. When creating or editing you choose today or later. |
| **Invoiced until** | Until when invoicing has been done. If you leave it empty, the display follows **Paid until**. |
| **Type** | Distinguishes own stay from rental. |
| **Rent frequency** | Records the rhythm of the rent for administrative follow-up. |
| **Price** | Follows the terrain by default, but can be adjusted per occupation. |

## Common scenarios [#veelvoorkomende-scenarios]

### A new guest checks in [#een-nieuwe-gast-checkt-in]

1. Find the customer or add them.
2. Create an occupation on the terrain on the customer profile.
3. Enter the start meter reading, or let Tillor take over the last reading.
4. From now on Tillor links the consumption of the meters on that terrain to this customer.

### A guest leaves [#een-gast-vertrekt]

1. Choose **Delete** on the occupation.
2. Choose the departure date and enter the end meter readings.
3. Confirm. Tillor closes the consumption periods and the terrain is available again.

### A customer moves to another terrain [#een-klant-verhuist-naar-een-ander-terrein]

1. End the current occupation with the end meter readings of the old terrain.
2. Create a new occupation on the new terrain with the start meter readings.
3. Tillor keeps the consumption periods per terrain separate.

## Problems? [#problemen]

<Accordions>
<Accordion title="The terrain is not in the selection list">
Only terrains without an active occupation are in the list. If another customer still has the terrain, end that occupation first. If nothing is available, you see **No available terrains found.** If all terrains are missing and you see **Something went wrong while loading the terrains.**, reload the page.
</Accordion>
<Accordion title="The occupation cannot be created because the terrain is already occupied">
Another user beat you to it and took the terrain. Reload the customer page, choose another terrain or first end the other customer's occupation.
</Accordion>
<Accordion title="I cannot choose a date in the past for Paid until">
That is intended. When creating or editing, **Paid until** only accepts today or later.
</Accordion>
<Accordion title="The end meter readings do not appear when deleting">
First choose under **Date** the day on which the occupation ends. A field then appears per meter. If the terrain has no meters, there is no field.
</Accordion>
<Accordion title="I cannot type a reading for a meter">
That is a meter that sends readings by itself. Choose an existing reading via **Select a meter reading**. If it says **No meter readings available**, the meter has not sent a reading yet.
</Accordion>
<Accordion title="Tillor says: Could not create invoice">
Usually there is no product with the action **Extend occupation period**. Create one, see [Products](/producten), and try again. If you extend all occupations at once, also check that they belong to the same customer.
</Accordion>
<Accordion title="Tillor shows Check before continuing when extending">
There is already a draft for this terrain, or the terrain has been invoiced until a date that has not been paid yet. Read the message. With **Create draft anyway** you deliberately continue, with **Open draft ...** you first check the existing draft.
</Accordion>
<Accordion title="I deleted an occupation by accident">
That cannot be undone. Create a new occupation on the same terrain. The consumption up to the end date of the old occupation has been kept.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Occupation**: a customer on a terrain for a period. See [occupation](/begrippen#bezetting).
- **Terrain**: the pitch itself, with any meters. See [terrain](/begrippen#terrein).
- **Paid until**: the date until which the customer has paid in advance.
- **Invoiced until**: the date until which invoicing has already been done.
- **Consumption period**: the period in which the consumption of a meter is allocated to one customer. See [consumption batch](/begrippen#verbruiksbatch).
- **Rent frequency**: the rhythm of the rent, for example yearly or per half year.

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" description="Add and manage customers" />
  <Card title="Meter management" href="/meterbeheer" description="How meters are read and linked to occupations" />
  <Card title="Consumption batches" href="/meterbeheer/consumptie-batches" description="How consumption periods are tracked and invoiced" />
  <Card title="Practical examples" href="/praktijk" />
  <Card title="Winning a seasonal customer" href="/praktijk/seizoensklant-binnenhalen" />
  <Card title="A static caravan becomes available" href="/praktijk/stacaravan-komt-vrij" />
</Cards>


# VAT & Tax (/en-GB/boekhouden/belasting)

Here you can read how VAT ends up on your invoices and how Tillor checks a customer's VAT number. The check runs through VIES, the European service for looking up a VAT number.

## VAT rates [#btw-tarieven]

VAT rates are set per product. Go to **Administration > Products** and open a product to choose the **VAT %** from the available rates (by default 0%, 6%, 9%, 12% and 21%).

<DocScreenshot src="/screenshots/producten/products-list.png" alt="Products overview with the VAT column per product" />

## Reverse charge and other regimes without VAT [#btw-verlegd-en-andere-regimes-zonder-btw]

Sometimes you do not charge VAT, but that is not simply a 0% rate: the customer has to declare the VAT themselves, or the supply is exempt. That is why the **VAT %** list of a product contains five regimes below the rates. If you choose one, the product is set to 0% and Tillor knows why.

| Regime | When | Box in the VAT return |
|--------|------|-----------------------|
| **Reverse charge (EU services)** | A service for a VAT-registered customer in another EU country | 44 |
| **Reverse charge (co-contractor)** | Work on immovable property for a Belgian VAT-registered customer who files periodic returns | 45 |
| **Intra-community supply** | Goods you send to a VAT-registered customer in another EU country | 46 |
| **Export outside the EU** | Goods that leave the EU | 47 |
| **VAT exempt** | A supply that is exempt by its nature (article 44 of the VAT Code) | 00 |

A regime does four things that a plain 0% rate does not:

- **On the invoice** the line shows `0%*`, with the legal statement for the regime below the totals, for example *Reverse charge: VAT is payable by the customer*. If two regimes appear on one invoice, the second gets `**`.
- **Booking only works with a VAT number** for the two reverse charge regimes and for an intra-community supply. Enter the number on the customer profile; it then also appears on the invoice.
- **To the accounting system** the line goes with the code of the regime, so it lands in the right box of your VAT return. See [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol#btw-regimes).
- **Over Peppol** the line gets the VAT category of the regime.

<Callout type="warn" title="You decide which regime applies">
Tillor does not check whether a customer or a supply qualifies for a regime. If in doubt, ask your accountant.
</Callout>

## VAT number validation [#btw-nummer-validatie]

When you enter a VAT number on the customer profile, Tillor checks it automatically through the European VIES service as soon as the country has been filled in.

### How it works [#hoe-het-werkt]

1. Open **Customers > customer** (section **Customer Details**)
2. Set the **country** and enter the VAT number (for example `NL123456789B01` or `BE0123456789`)
3. Tillor validates the number automatically (after a short pause)
4. For a valid VAT number a green tick appears; click it for company details from VIES
5. Want to copy the name and address? Click **Apply company address** in that window (the company name goes in the first name field)
6. For an invalid VAT number a red icon appears with an explanation

<DocScreenshot src="/screenshots/klanten/customer-profile.png" alt="Customer profile with Customer Details and VAT fields" />

<Callout type="info">
VAT validation works for all EU countries. For non-EU companies you can enter the VAT number manually without validation.
</Callout>

### Supported countries [#ondersteunde-landen]

Validation supports all EU member states, including the Netherlands (NL), Belgium (BE), Germany (DE), France (FR) and all other EU countries.

### Country code on the invoice PDF [#landcode-op-de-factuur-pdf]

On the invoice PDF, Tillor adds a missing country code automatically for countries where that is the usual way of writing it: if you enter `0123456789` for a Belgian customer, the invoice shows `BE0123456789`. This does not happen for Spain, Italy and Portugal, because the national tax number is written there without a country code (a Spanish NIF such as `B04876793` therefore stays unchanged). If you type the country code in the field yourself, it is always kept.

## Belgian customers and Peppol [#belgische-klanten-en-peppol]

For Belgian customers with a VAT number, a **Peppol ID** must be set on the **Invoicing** tab before you can book invoices. This is a legal requirement for B2B invoicing in Belgium.

See the [Peppol documentation](/boekhouden/peppol) for more information.

## VAT on invoices [#btw-op-facturen]

All invoice lines automatically show the right VAT rate based on the linked product. On the invoice you see **Subtotal**, **VAT** and **Total**; the invoice PDF also contains an overview per VAT rate.

<Callout type="info" title="Adjusting VAT per line">
Do you have permission to change organisation settings? Go to **Settings > Invoicing** and switch on **VAT rate dropdown on draft invoice lines**. **Draft invoices** then get a column for choosing the rate per line (the options follow the rates configured for your organisation). When you select a product, the product's default rate stays the starting value. In the same column you also choose a [regime without VAT](#btw-verlegd-en-andere-regimes-zonder-btw) for a single line.
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="The customer's VAT number gets a red icon">
Tillor could not confirm the number through VIES. Check the country and the number. For a company outside the EU you can also enter the number without validation.
</Accordion>
<Accordion title="I cannot book an invoice with reverse charge">
The customer has no VAT number. Reverse charge and an intra-community supply only exist for a VAT-registered customer. Enter the number under <UIPath>Customers > customer</UIPath>, section **Customer Details**, and book again.
</Accordion>
<Accordion title="I cannot send an invoice with two regimes over Peppol">
A Peppol invoice can carry only one reason for the absence of VAT. Put the lines of each regime on their own invoice.
</Accordion>
<Accordion title="I am missing a VAT rate on a product">
You can only choose from the permitted rates, by default 0%, 6%, 9%, 12% and 21%.
</Accordion>
<Accordion title="I cannot choose the VAT rate on an invoice line">
The column with rates only appears on draft invoices, and only when **VAT rate dropdown on draft invoice lines** is switched on.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Products" href="/producten" description="Link VAT rates to products" />
  <Card title="Peppol" href="/boekhouden/peppol" description="Electronic invoicing in Belgium" />
  <Card title="Invoices" href="/facturen" description="Create and book invoices" />
</Cards>


# Payment methods (/en-GB/boekhouden/betalingsrapporten/betaalmethodes)

Payment reports contain payments from different sources. Only **Mollie** and **internal transfers** are sent to the accounting system.

| Method | On the Tillor report | To accounting |
|---------|-------------------|------------------|
| [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie) | Yes (via Mollie settlement) | Yes |
| [Bank accounts](/boekhouden/betalingsrapporten/betaalmethodes/ponto) | Yes (on the payment day) | No |
| [Internal transfer](/boekhouden/betalingsrapporten/betaalmethodes/internal-transfers) | Yes | Yes |

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-report-detail.png" alt="Payment report with payments from different sources" />

```mermaid
flowchart LR
  Mollie[Mollie] --> R[Tillor-rapport]
  Bank[Bankrekeningen] --> R
  Internal[Interne overboeking] --> R
  R --> BH[Boekhouding]
  Mollie --> BH
  Internal --> BH
```

## See also [#zie-ook]

<Cards>
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Bank accounts" href="/boekhouden/betalingsrapporten/betaalmethodes/ponto" />
  <Card title="Internal transfer" href="/boekhouden/betalingsrapporten/betaalmethodes/internal-transfers" />
</Cards>


# Internal transfers (/en-GB/boekhouden/betalingsrapporten/betaalmethodes/internal-transfers)

With **Internal Transfer** you move an outstanding amount from one invoice to another **booked** invoice of the **same customer**. Tillor creates a positive payment on the invoice you are paying and a linked negative payment on the target invoice.

See [Internal transfer - Registering](/betalingsverwerking/interne-overboeking) for the step-by-step registration process with screenshots.

## In payment reports [#in-betalingsrapporten]

- Internal transfers appear on the Tillor payment report of the day you register them (Brussels time).
- They **do** go to the accounting export: together with Mollie payments, and **not** together with bank accounts or other manual methods (cash, bank transfer, ...).
- In the accounting export every line appears as `Tillor - Interne overboeking - {factuurnummer}`, linked to the invoice and customer concerned.

## See also [#zie-ook]

<Cards>
  <Card title="Registering" href="/betalingsverwerking/interne-overboeking" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Bank accounts" href="/boekhouden/betalingsrapporten/betaalmethodes/ponto" />
</Cards>


# Mollie (/en-GB/boekhouden/betalingsrapporten/betaalmethodes/mollie)

Mollie payments (iDEAL, credit card, Bancontact, terminal, etc.) are synchronised in Tillor and linked to payment reports via the **Mollie settlement**.

## Connecting in Tillor [#koppelen-in-tillor]

1. Go to **Settings > Integrations** and choose **Mollie** in the list.
2. Follow the Mollie OAuth steps if the connection is not yet active.
3. On the detail page, under **Website profile**, choose a **Primary profile** (the Mollie website profile for payments and synchronisation). Optionally choose a **Default terminal** (the card device Tillor suggests by default on invoices).
4. Click **Save**. Without a primary profile, Mollie payments do not work in Tillor; a terminal is only needed for card payments.

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/betaalmethodes/mollie/mollie-marketplace-install.png" alt="Settings > Integrations with Mollie in the list" />

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/betaalmethodes/mollie/mollie-connection-settings.png" alt="Mollie settings with Primary profile and Default terminal" />

### Status icons in the selection lists [#statusiconen-in-de-keuzelijsten]

To the left of the profile and terminal name is a coloured icon. That is the status at Mollie, not the name itself.

| Icon | Website profile | Terminal |
|-------|----------------|----------|
| Green (tick) | Verified - suitable for live payments | Active - ready for card payments |
| Orange (clock) | Not verified yet at Mollie | Pending - not yet active |
| Red (prohibited) | Blocked | - |
| Grey | - | Inactive |

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/betaalmethodes/mollie/mollie-profile-select-open.png" alt="Primary profile open with status icon next to the profile name" />

Preferably choose a **verified** profile. An **active** terminal is optional and only needed if you want Tillor to suggest card payments. Without a primary profile, payments and synchronisation do not run.

## Mollie settlements [#mollie-settlements]

As long as Mollie has not yet paid out a payment, it appears as an **advance** on the open draft report. Only when the report is finalised does the settlement decide which report it belongs to; see [Mollie payments on the draft](/boekhouden/betalingsrapporten#mollie-betalingen-op-het-concept).

For **report day D**, Tillor looks for a settlement in this order:

1. Settlement **created on day D**
2. Otherwise settlement **created on day D+1** (typically: revenue of D is paid out the next morning)

```mermaid
flowchart TD
  D[Rapportdag D] --> E{Settlement aangemaakt op D?}
  E -- ja --> F[Koppel aan rapport D]
  E -- nee --> G{Settlement aangemaakt op D+1?}
  G -- ja --> F
  G -- nee --> H[Nog geen Mollie op dit rapport]
  F --> I[Eén settlement-id per rapport]
```

**Fixed rules:**

- Every settlement id appears on **at most one** payment report.
- Does a report already have a settlement? That link **stays**; Tillor does not replace it.
- If both D and D+1 are missing (for example a weekend): the report may already exist with only manual/bank account payments; as soon as Mollie publishes, the daily synchronisation adds Mollie.

## Examples [#voorbeelden]

| Report day D | Settlement created at Mollie | Result |
|--------------|----------------------------------|-----------|
| Tue 20 May | Tue 20 May (`stl_aaa`) | `PAYR/2026/0140` (20 May) gets `stl_aaa` |
| Tue 20 May | Wed 21 May early (`stl_bbb`) | `PAYR/2026/0140` (20 May) gets `stl_bbb` (rule D+1) |
| Sun 18 May | Mon 19 May (`stl_ccc`) | `PAYR/2026/0138` (Sunday) gets `stl_ccc`, **not** the Monday report |
| Mon 19 May | Mon 19 May (`stl_ccc`) | Monday report looks for its own settlement (`stl_ddd` on Tue or later), not `stl_ccc` |
| Sat 17 May | No settlement Sat/Sun/Mon morning | Report 17 May: manual/bank accounts first; Mollie follows once the settlement exists |
| Tue 20 May | Report already existed without settlement | Next run 09:00: settlement is still added on 20 May, payments linked |

**In practice (D+1):** revenue of **Tuesday 20 May** is in settlement `stl_6necch`, created **Wednesday 21 May** at 06:08. Tillor links `stl_6necch` to **`PAYR/2026/0140` (report day 20 May)**, not to the report of 21 May.

**Existing report:** was `PAYR/2026/0140` already in Tillor without a linked Mollie settlement and with two manual lines? After the synchronisation, `stl_6necch` is still linked; existing lines stay; Mollie payments from that settlement are added.

**Already linked:** report **15 May** already has `stl_old`. Tillor does **not** change that id. Loose Mollie payments with the same settlement id still end up on the report that already has that settlement.

## Synchronisation on existing reports [#synchronisatie-op-bestaande-rapporten]

After creating missing reports, Tillor looks **only at reports without a linked Mollie settlement** in a rolling window of **one calendar month before yesterday** up to yesterday. Reports that already have a Mollie settlement are **not** fetched again via the Mollie settlement list.

```mermaid
flowchart TD
  start[Synchronisatie<br/>ma-za 09:00] --> scope[Rapportdag vanaf<br/>maand vóór gisteren t/m gisteren]
  scope --> nullOnly[Alleen rapporten<br/>zonder Mollie-afrekening]
  nullOnly --> U{Zoek settlement voor D of D+1}
  U -- gevonden --> V[Settlement vastleggen]
  U -- niet --> W[Geen Mollie-stap]
  V --> X[Ongekoppelde Mollie-betalingen<br/>uit settlement koppelen]
  X --> Z[Betalingen met dezelfde<br/>settlement-id op dat rapport]
```

Payments that already have a settlement id from Mollie but are not yet on a report end up on the report with the same settlement id.

## Mollie payments in Tillor [#mollie-betalingen-in-tillor]

Tillor fetches Mollie payments **every 15 minutes** (per organisation with an active Mollie connection). Webhooks from Mollie also work immediately: a payment becomes **Paid**, **Refunded** or **Charged Back** straight away, even if it originated outside Tillor (for example a card machine). If in doubt, or after a missed webhook: **Sync** in the action menu of the payment.

A payment ends up on a report if:

- it is in the linked **settlement** (Mollie's list), or
- the payment already has a settlement id that belongs to the report.

| Type in report | Meaning |
|-----------------|-----------|
| Known | Payment linked to an invoice in Tillor |
| Unknown | No invoice link in Tillor → suspense account 499000, unless you send accounting details along via Mollie |

Settlement payments that do **not** exist in Tillor appear as an unknown Mollie payment on the report.

On a payment report you see linked Mollie payments in the **Payments** table:

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-report-detail.png" alt="Payment report detail with payments and Send to accounting" />

## Mollie metadata [#mollie-metadata]

Do you have a till or another system that creates Mollie payments itself? You can steer Tillor through metadata on that payment: linking to an invoice or [payment group](/betalingsverwerking/groepen), or straight to accounting. The fields are described under [Mollie metadata](/ontwikkelaars/mollie-metadata).

## See also [#zie-ook]

<Cards>
  <Card title="Payment reports" href="/boekhouden/betalingsrapporten" />
  <Card title="Payment groups" href="/betalingsverwerking/groepen" />
  <Card title="Bank accounts" href="/boekhouden/betalingsrapporten/betaalmethodes/ponto" />
  <Card title="Internal transfers" href="/boekhouden/betalingsrapporten/betaalmethodes/internal-transfers" />
  <Card title="Admisol" href="/boekhouden/betalingsrapporten/boekhoudsystemen/admisol" />
  <Card title="Mollie metadata (API)" href="/ontwikkelaars/mollie-metadata" />
</Cards>


# Bank accounts (/en-GB/boekhouden/betalingsrapporten/betaalmethodes/ponto)

The bank connection links to your bank account via open banking and fetches transactions automatically.

## How it works [#hoe-het-werkt]

1. **Transactions**: Every 5 minutes Tillor fetches bank transactions from your bank
2. **Structured communication**: +++123/4567/89002+++ or invoice number (INV/2024/0001) is read
3. **Matching**: Tillor looks for a matching invoice → a payment is created and linked
4. **Duplicate manual transfer**: If there is already a manual transfer on the same invoice with the same amount, it is removed so the payment does not count twice
5. In Tillor you see that payment as a **Bank Transfer**

## Connecting [#koppelen]

The integration is called **Bank accounts** and is found at <UIPath>Settings > Integrations > Bank accounts</UIPath>. You enter a **Client ID** and **Client Secret**; a Tillor administrator helps you with the setup and guides the onboarding.

## Viewing bank transactions [#banktransacties-bekijken]

Imported bank transactions are on **Administration > Bank transactions**. That page is only visible to users with the **View bank transactions** permission. Without that permission you do not see the page in the menu.

<DocScreenshot src="/screenshots/boekhouden/bank-transactions/bank-transactions-list.png" alt="Bank transactions overview with Invoice column" />

In the **Transactions** table, the **Invoice** column sits between **Value date** and **Communication**:

- Is the transaction already on an invoice? Then you see the invoice number as a link (for example `INV/2026/0001`).
- No link yet? Open the action menu (three dots) at the end of the row and choose **Assign to invoice**. If necessary Tillor first creates a payment and links it to the transaction. For this you need the **Assign payment** permission; without it you do not see this action in the menu.
- Is the transaction already on an invoice? Open the same action menu and choose **Unassign from invoice** to remove the link (both manually and automatically matched).

Click the (i) icon next to the IBAN to open the detail panel of that transaction: amount, value date, counterparty and IBAN, communication, the details of the account statement (bank reference, ordering party reference, card number, ...), the linked invoice, payment and payment report, and the references. The action menu is also at the top of that panel.

In the action menu you can also choose:

- **Create task** to attach a task to the transaction, for example to process a payment manually. The task shows the transaction as a linked item; click it to open the detail panel. See [Linked items](/taken/taakdetails#gekoppelde-items).
- **Copy link** for a link that opens the **Bank transactions** page with the detail panel of that transaction, for example to paste in a comment or a message.

<DocScreenshot src="/screenshots/boekhouden/bank-transactions/bank-transactions-assign-dialog.png" alt="Assign to invoice dialog for a bank transaction" />

You see the same **Invoice** column on a **payment report** in the **Bank account transactions** table, as long as you have the read permission.

## Unassigning [#ontkoppelen]

On **Administration > Bank transactions** (and on a payment report in **Bank account transactions**) you open the action menu on a linked row and choose **Unassign from invoice**. That works for both manually linked and automatically matched transactions.

On **Administration > Payments**, **Unassign from invoice** only appears for payments that you yourself linked or moved to an invoice. That prevents you from accidentally removing a correct automatic link via the payments overview.

<DocScreenshot src="/screenshots/betalingen/payment-unassign-menu.png" alt="Payment action menu with Unassign from invoice" />

## Syncing manually [#handmatig-synchroniseren]

On **Administration > Bank transactions** and on a **payment report** (**Bank account transactions** table) the **Sync bank account** button appears if the bank connection is installed and you have the **Sync bank transactions** permission. With it you request a fresh bank synchronisation; Tillor then imports new transactions and tries to link them to invoices.

Without a bank connection or without that permission the button does not appear. Tillor also imports new transactions automatically, every 5 minutes.

You set both permissions via **Settings > Permissions** (group **Bank transactions**).

## In payment reports [#in-betalingsrapporten]

Bank transfers **do** appear on the Tillor payment report of the payment date (Brussels time), together with manual payments on that day. They do **not** go to the accounting export: only Mollie and internal transfers do. The bank connection is mainly meant for automatic linking to invoices in Tillor.

<Callout type="idea" title="Automatic matching">
Customer transfers with a structured communication → Tillor fetches from your bank → invoice is matched → payment + invoice paid.
</Callout>

## See also [#zie-ook]

<Cards>
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Internal transfers" href="/boekhouden/betalingsrapporten/betaalmethodes/internal-transfers" />
</Cards>


# Admisol (/en-GB/boekhouden/betalingsrapporten/boekhoudsystemen/admisol)

Admisol is an accounting package that Tillor supports for sending payment reports. Payment reports are converted to Admisol XML and sent to Admisol automatically or manually.

## Installation [#installatie]

1. Go to **Settings** (marker **1** in the screenshot) and choose **Integrations**.
2. Find **Admisol** in the integration list (marker **2**) and open the detail page.
3. On the detail page, enter your **Company ID** and **Web Service Key** (details from Admisol) and click **Install**.

<DocScreenshot src="/screenshots/boekhouden/boekhoudsystemen/admisol-marketplace-install.png" alt="Settings > Integrations with Admisol in the list" />

<DocScreenshot src="/screenshots/boekhouden/boekhoudsystemen/admisol-credentials-dialog.png" alt="Admisol detail with Company ID and Web Service Key" />

## Sending automatically [#automatisch-versturen]

When a payment report **changes in substance** (for example after linking payments or after **Recalculate report**):

1. Tillor checks whether Admisol is installed for the organisation
2. The report is converted to Admisol XML
3. The XML is sent to Admisol

During the **daily creation** (09:00), Tillor works through the missing days **from oldest to newest**. Each new report is only sent to Admisol once the previous report has received a reply (acceptance or rejection). If sending fails, Tillor stops for that organisation until the next run.

The [draft report](/boekhouden/betalingsrapporten#concept-en-definitief) of the current day is sent to Admisol as soon as it contains a Mollie payment or internal transfer, and after that only again when the booking changes. Cash payments on the draft do not trigger a send. Mollie payments on a draft are booked against the supplier Mollie **without a document reference**; Admisol books that as an **advance** ("still to be received"). Refunds that Mollie has not yet withheld appear as a second, separate advance line on Mollie ("still to be withheld"). On the final send, the actual payout with bank costs takes their place, and payments that were not in the settlement move as an advance to the next draft. While the report is a draft, Admisol shows the document reference as `PAYR/2026/0275 - Concept`; that suffix disappears on the final send. If the report becomes final on the next working day, Tillor sends it again, now with the Mollie settlement, under the **same document number and the same booking date**.

If an automatic send fails, you get a notification and a line appears on the events timeline of the report.

## Sending manually [#handmatig-versturen]

1. Go to **Administration > Payment Reports**
2. Open the report you want to send
3. Click **"Send to accounting"**

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-report-detail.png" alt="Payment report with Send to accounting" />

## Which payments are included? [#welke-betalingen-gaan-mee]

Only payments with:

- **Mollie** as provider, or
- **Internal Transfer** as payment method

Bank account payments are not sent to accounting.

## Partial refund (Mollie) [#gedeeltelijke-terugbetaling-mollie]

If a linked Mollie payment has been partly or fully refunded, Tillor sends the **original payment amount** on the payment report of the **Mollie settlement in which the payment arrived**. The **refund** appears as a negative line on the report of the **settlement in which Mollie deducts the refund** (label *Terugbetaling*). That can be later settlements; multiple refunds each get their own line on the report of their settlement. That way the report matches what Mollie actually pays out. Because refunds are only booked on that settlement day, no extra line on suspense account **499000** (*restant saldo*) is needed.

## Bank costs per Mollie invoice [#bankkosten-per-mollie-factuur]

Mollie withholds its costs from every payout and invoices them once a month. Tillor therefore books the withheld costs **per invoice period**: each line carries the month for which Mollie invoices the costs, for example *Bankkosten 01/2026*. A payout in the first days of the month often still contains costs of the previous month; those then appear as a separate line on the same report.

All lines of the same period add up to the amount of that month's Mollie invoice. Lines of the current month stay open until Mollie issues the invoice.

### On the supplier Mollie [#op-de-leverancier-mollie]

The withheld costs are not a second cost: Mollie uses them to pay its own invoice. Tillor therefore books them on the **supplier Mollie**, without a document reference. The cost and the VAT only come in through the Mollie purchase invoice. Each month you match the invoice on the supplier Mollie against the *Bankkosten* lines of that period; together they are the same size. A correction via a miscellaneous entry is not needed.

Mollie usually withholds the costs of a payment at the moment the payment comes in, even if the payout follows later. A draft report therefore already books those costs per invoice period, and the advance on Mollie is the amount after costs. A card payment that Mollie is still holding has no withheld cost yet: that cost only appears on the report with the payout. Until then the month on the supplier Mollie is not yet complete.

In Admisol, **do not match lines of a draft report** (document reference ends in *- Concept*). On the final send Admisol replaces the lines of the report, and matches on those lines may disappear. That can also happen when you resend a final report, even if nothing has changed: check the matches on the supplier Mollie afterwards.

## Balance reserve [#balansreserve]

Mollie sometimes withholds part of the payout as a **balance reserve**: money you are still owed, but that Mollie temporarily holds back. Because it is neither a cost nor a refund, Tillor books that amount on the **supplier Mollie** with the label *Balansreserve*, just like the payout itself. That way it stays visible as an outstanding credit at Mollie instead of on the suspense account. If Mollie later releases the reserve, the report of that settlement shows an opposite *Balansreserve* line that books the credit off again. You do not have to do anything; on the supplier Mollie the two lines cancel each other out.

## Invoices that are already matched in Admisol [#facturen-die-in-admisol-al-afgepunt-zijn]

Admisol refuses a line on an invoice or credit note that you have manually matched in Admisol against a booking other than the payment report. Tillor then books the lines of that one invoice on the customer **without a document reference**, so the report still goes through. The amounts and the customer stay the same; you only match the link with the invoice again yourself in Admisol. On the events timeline of the report, the sent XML shows which invoice it concerns.

## Accounting parameters [#boekhoudparameters]

After installation you set the accounting parameters via **Settings** on the Admisol app (same screen as Company ID and Web Service Key). They include document types for invoices and settlements, the Mollie supplier code, the default general ledger account for invoice lines, and the default department. Missing fields get Tillor default values.

Unknown Mollie payments are booked on the suspense account **499000**. Per payment you can also pass department and financial year via [Mollie metadata](/ontwikkelaars/mollie-metadata#directe-boekhoudmetadata-tillorbookkeeping).

### VAT regimes [#btw-regimes]

An invoice line with a [regime without VAT](/boekhouden/belasting#btw-verlegd-en-andere-regimes-zonder-btw) goes to Admisol with its own **tax address profile** and **tax code**. Together they determine which box of the VAT return the line ends up in. The defaults are those of a new Admisol file:

| Regime | Tax address profile | Tax code | Box |
|--------|------------------|----------|---------|
| Reverse charge (EU services) | `EU` | `vd21` | 44 |
| Reverse charge (co-contractor) | `MED` | `v21` | 45 |
| Intra-community supply | `EU` | `v21` | 46 |
| Export outside the EU | `EXP` | `v21` | 47 |
| VAT exempt | `NA` | `v0` | 00 |

If your file uses other codes, adjust them in the accounting parameters: per regime there is a field for the tax address profile and one for the tax code. You find your file's codes in Admisol under **Instellingen > BTW-instellingen > Tax-relaties**. The customer record in Admisol keeps its own tax address profile; only the invoice line gets the one from the regime.

## See also [#zie-ook]

<Cards>
  <Card title="Odoo" href="/boekhouden/betalingsrapporten/boekhoudsystemen/odoo" />
  <Card title="Exact Online" href="/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online" />
  <Card title="Mollie" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
</Cards>


# Exact Online (/en-GB/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online)

Exact Online is the accounting package that many Dutch parks and their offices use. Tillor links **customers**, **booked invoices** and **payment reports** to Exact Online. The integration is **available on request** - not yet as self-service in the App Marketplace.

<Callout type="info" title="On request">
Do you want to connect Tillor to Exact Online? Request activation via the [demo](https://tillor.eu/demo) or email **support@tillor.eu**. We set up the integration together with your accountant.
</Callout>

## What the integration covers [#wat-de-koppeling-dekt]

The intended export follows the same chain as [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol) and [Odoo](/boekhouden/betalingsrapporten/boekhoudsystemen/odoo). We agree the exact mapping of journals and revenue accounts at activation.

- **Customers** from Tillor to Exact Online
- **Booked invoices** (lines and VAT)
- **Payment reports** - only **Mollie** and **internal transfers**, as with the other accounting exports

Bank account payments do appear on the Tillor report, but do not go to the accounting export. See [accounting systems](/boekhouden/betalingsrapporten/boekhoudsystemen).

## No self-service yet [#nog-geen-zelfbediening]

You will not yet find Exact Online under **Settings > Integrations**. Administration choice, general ledger mapping and first export are done together with Tillor support. There is no installation form to fill in yourself.

<Callout type="warn" title="One active accounting system">
Tillor exports to one accounting package per organisation. If you already use Admisol or Odoo, we agree which system stays active.
</Callout>

## Requesting [#aanvragen]

1. Note your Exact Online administration (division) and whether your accountant will be looking along.
2. Request the integration via [tillor.eu/demo](https://tillor.eu/demo) or **support@tillor.eu**.
3. Tillor schedules the activation and the mapping of journals and revenue accounts.

## See also [#zie-ook]

<Cards>
  <Card title="Admisol" href="/boekhouden/betalingsrapporten/boekhoudsystemen/admisol" />
  <Card title="Odoo" href="/boekhouden/betalingsrapporten/boekhoudsystemen/odoo" />
  <Card title="Accounting systems" href="/boekhouden/betalingsrapporten/boekhoudsystemen" />
</Cards>


# Overview (/en-GB/boekhouden/betalingsrapporten/boekhoudsystemen)

Tillor supports integration with accounting software for sending payment reports. Payment reports are converted to the format of your accounting package (currently Admisol) and sent automatically or manually. [Exact Online](/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online) is available on request.

## Supported systems [#ondersteunde-systemen]

| System | Status |
|---------|--------|
| [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol) | Supported |
| [Odoo](/boekhouden/betalingsrapporten/boekhoudsystemen/odoo) | Customers and booked invoices |
| [Exact Online](/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online) | On request |

## General [#algemeen]

- **Automatic**: When a payment report is created or meaningfully updated, it is sent to Admisol (only if Admisol is installed)
- **Manual**: Via **Administration > Payment Reports** → open report → **Send to accounting**
- **Which payments**: Only **Mollie** and **internal transfers**. Bank accounts do appear on the Tillor report, but do not go to the accounting export.

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-report-detail.png" alt="Payment report with manual Send to accounting" />

## See also [#zie-ook]

<Cards>
  <Card title="Admisol" href="/boekhouden/betalingsrapporten/boekhoudsystemen/admisol" />
  <Card title="Odoo" href="/boekhouden/betalingsrapporten/boekhoudsystemen/odoo" />
  <Card title="Exact Online" href="/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online" />
</Cards>


# Odoo (/en-GB/boekhouden/betalingsrapporten/boekhoudsystemen/odoo)

The Odoo integration in Tillor exports **customers** and **booked invoices** to Odoo. Payment reports to Odoo will follow in a later release; until then, use [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol) if you want payment reports sent on automatically.

## Installation [#installatie]

1. Go to **Settings** and open the App Marketplace.
2. Find the **Odoo** card and click **Install**.
3. First fill in the following under **Connection**:
   - **Odoo URL** - for example `https://mijnbedrijf.odoo.com` or just `mijnbedrijf` (Tillor then completes the `.odoo.com` URL)
   - **Username** - a user with API access
   - **API key** - an API key (Odoo: user profile > API keys)
4. Click **Continue to database**. Tillor fetches the available databases (or lets you enter the name manually).
5. Choose the database under **Database** and complete the installation.

When you save, Tillor tests the connection.

<Callout type="info" title="One active accounting system">
If both Admisol and Odoo are installed, Tillor uses **Admisol** for exports (fixed priority). Only install Odoo if you no longer use Admisol.
</Callout>

## Accounting parameters (Odoo app) [#boekhoudparameters-odoo-app]

After installation, you set the export parameters under **Settings** on the Odoo app (next to the URL, database, username and API key). Tillor fetches sales journals and income accounts live from Odoo; you pick them through a search field (code and name).

| Field in the app | Default | Meaning |
|---|---|---|
| **Sales journal code** | INV | Sales journal in Odoo with this code |
| **Default income account** | 700000 | Income account used when the invoice line has no ledger number of its own |
| **Post invoices automatically** | off | Post in Odoo straight after the export |
| **Attach invoice PDF** | on | Tillor invoice PDF as an attachment on the Odoo invoice |
| **Attach Peppol UBL** | on | Peppol UBL as an extra attachment (only if Tillor already has that UBL) |

For each invoice line, Tillor first looks for an Odoo account with the same code as the line's **ledger number**; otherwise it uses the default income account. For VAT, Tillor looks for a sales tax in Odoo with the same percentage as on the line.

### VAT regimes [#btw-regimes]

An invoice line with a [regime without VAT](/boekhouden/belasting#btw-verlegd-en-andere-regimes-zonder-btw), such as reverse charge, needs its own sales tax in Odoo: an ordinary 0% ends up in the wrong box of your VAT return. So in the export settings, for each regime you use, enter the **name of the sales tax in Odoo**, exactly as it appears in Odoo under **Accounting > Configuration > Taxes** (in a Belgian Odoo, for example, `0% EU S` for EU services). There are five fields: reverse charge (EU services), reverse charge (co-contractor), intra-community supply, export outside the EU and VAT exempt.

If the field for a regime is empty or the tax does not exist in Odoo, the export of that invoice stops with an error message. Enter the name and send the invoice again.

## Invoice PDF in Odoo [#factuur-pdf-in-odoo]

With **Attach invoice PDF** (on by default), Tillor uploads the same PDF as in Tillor. For a new export this happens **before** posting in Odoo, so the preview on the right of the invoice can be linked. The file name follows the Tillor invoice number (e.g. `INV_2026_0001.pdf`). Tillor also sets that PDF as the main attachment on the Odoo invoice.

On the **Events** of the Tillor invoice you can see whether the export succeeded, including customer, invoice, PDF and UBL.

- If the Odoo invoice already exists (same reference: the Tillor invoice number), Tillor updates the customer, lines, dates and payment reference. If the invoice was already posted in Odoo, Tillor first sets it back to draft, changes the data and posts it again when **Post invoices automatically** is on or the invoice was already posted.
- After that, PDF and UBL attachments are replaced or added when those options are on.
- If the upload fails after a newly created draft invoice, that Odoo invoice is deleted so a following export can try again.

## Peppol UBL in Odoo [#peppol-ubl-in-odoo]

With **Attach Peppol UBL** (on by default), Tillor uploads the Peppol UBL as an extra attachment on the Odoo invoice. The file name follows the Tillor invoice number (e.g. `INV_2026_0001.xml`).

- Tillor does not generate UBL itself: the file only becomes available after a successful Peppol delivery.
- If the UBL is not ready at the time of export, Tillor skips the UBL attachment; as soon as the UBL arrives, it is still added to the existing Odoo invoice.
- If the UBL upload fails, the whole Odoo export does **not** fail (unlike the PDF). Only a PDF error after a new invoice rolls back the Odoo draft.

## Invoices [#facturen]

- When you **book** or **rebook** an invoice, Tillor exports the invoice to Odoo automatically.
- Manually: invoice actions > export to accounting (the same button as for Admisol).
- Only invoices with the status **Booked** are exported.
- If an Odoo invoice with the same Tillor invoice number already exists, no second invoice is created. Tillor updates the customer, lines and dates on that invoice (for example after moving it to another customer or rebooking) and replaces PDF/UBL attachments when those options are on.
- If the invoice PDF changes after a **payment** (or another amount on the document), Tillor replaces the existing PDF attachment in Odoo as soon as the new PDF is ready. No second Odoo invoice is created and no payment is posted in Odoo.

## Customers [#klanten]

Customers are updated or created in Odoo with the Tillor customer number as the reference. Existing partners with the same number are updated.

## Payment reports [#betalingsrapporten]

Sending payment reports to Odoo, automatically or manually, is **not yet available**. The daily payment report process skips Odoo without an error message.

## Requirements in Odoo [#vereisten-in-odoo]

- A sales journal with the configured code (default `INV`)
- G/L accounts with codes that match Tillor lines or the default income account
- Optional: sales VAT rates in Odoo with the same percentages as in Tillor

## See also [#zie-ook]

<Cards>
  <Card title="Admisol" href="/boekhouden/betalingsrapporten/boekhoudsystemen/admisol" />
  <Card title="Exact Online" href="/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online" />
  <Card title="Accounting systems" href="/boekhouden/betalingsrapporten/boekhoudsystemen" />
</Cards>


# Overview (/en-GB/boekhouden/betalingsrapporten)

A **payment report** is a daily overview of payments on one calendar day. Numbering: `PAYR/YYYY/DDDD` (day of the year, four digits; e.g. `PAYR/2026/0054`).

**Contents:** known and unknown payments, the Mollie payout (where applicable) and unlinked bank transactions from your bank accounts. A payout from Mollie is called a settlement in accounting: the amount Mollie puts into your bank account for a series of payments.

Your bookkeeper works with these reports. You do not have to create or close them. See also [How does it fit together?](/boekhouden#hoe-hangt-dit-samen).

## Draft and final [#concept-en-definitief]

A report has a **status**:

| Status | Meaning |
|--------|---------|
| **Draft** | The report of the **current day**. Today's payments (internal transfers, cash, bank accounts and Mollie) are already linked to it and the report already goes to the accounting. Mollie payments appear as an **advance**: money Mollie still has to pay out. There is no Mollie settlement yet and the report is not printed automatically yet. |
| **Final** | The day is closed. Tillor has linked the Mollie settlement (where applicable), printed the report and sent the final version to the accounting. |

Today's draft report is created automatically: by the 09:00 run, or earlier as soon as you register the first manual payment or bank account payment of that day. You never have to make a draft final yourself; Tillor does that at the next daily run after the day is over.

You recognise a draft by the **grey report number with a dotted underline** and the **Draft** badge, in the list (column and filter **Status**), on the detail page and everywhere the report is linked. The PDF of a draft has **(draft)** in the title. The report number and the booking date in the accounting stay the same when the draft becomes final.

### Mollie payments on the draft [#mollie-betalingen-op-het-concept]

Every paid Mollie payment that Mollie has not yet paid out goes straight onto the open draft report. In the accounting, the total appears as an **advance on the supplier Mollie**: this way you can see at any moment how much you still have coming from Mollie.

A **SEPA direct debit that is still running** counts in the same way, even when the collection only leaves for Mollie in a few days. The invoice is then already shown in Tillor as paid (pending), and so it is in the accounting. If the collection fails or is cancelled, the payment disappears from the draft again.

When the draft becomes final, Tillor compares the report with the Mollie settlement:

- Payments that are **in the settlement** stay on the report. The advance is replaced by the real payout, with the bank fees.
- Payments that are **not** in it (for example credit card with a later payout, or revenue after Mollie's cut-off) move on to the **next draft report** and stay there as an advance.
- If a payment from the settlement was already on a later draft, Tillor moves it back to the settlement's report.

Only recent payments are eligible: paid in the last month and still without a settlement at Mollie.

**Refunds** count immediately. A refund that Mollie has not yet deducted from a payout appears as a negative line on the open draft. In the accounting these remain two separate advances on Mollie: one for the payments still to be received and one for the refunds still to be deducted; they are not netted against each other. This also applies when the original payment is already on an older, final report: Mollie then deducts the amount from a later payout. As soon as a settlement offsets the refund, it appears on that settlement's report and disappears from the draft.

<Callout type="info" title="Draft in the accounting">
A draft goes to the accounting as soon as it contains something the accounting books (a Mollie payment or an internal transfer). After that, Tillor only sends it again if the booking changes, each time under the same document number. Changes are bundled: the dispatch leaves about ten seconds after the last change and after a minute at the latest, so that, for example, assigning a payment to an invoice results in one dispatch. A draft with only cash payments or bank account payments is therefore not sent, and an extra cash payment does not cause a new dispatch.
</Callout>

## Daily generation [#dagelijkse-generatie]

Every **working day at 09:00** (Monday to Saturday, Europe/Brussels time zone), Tillor processes all reports from **1 January up to yesterday** that are still missing or still **draft**, **from oldest to newest**: drafts are made final, missing days are created straight away as a final report. For each report Tillor waits for the Admisol response (success or error) before the next report is processed and sent. After that, Tillor opens **today's draft report**. For each organisation with an active Mollie integration, a **limited** synchronisation follows: reports **without** a Mollie settlement from **one calendar month before yesterday** up to yesterday (see [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie)).

```mermaid
flowchart TD
  start[Start werkdag 09:00] --> create[Concepten t/m gisteren definitief maken<br/>ontbrekende dagen aanmaken]
  create --> manual[Handmatige en bankrekeningbetalingen<br/>op rapportdag koppelen]
  manual --> rollover[Niet-uitbetaalde Mollie-betalingen<br/>naar volgend concept]
  rollover --> concept[Conceptrapport van vandaag openen]
  concept --> mollieCheck{Mollie actief?}
  mollieCheck -- nee --> done[Klaar]
  mollieCheck -- ja --> sync[Rapporten zonder settlement<br/>afgelopen maand bijwerken]
  sync --> done
```

### What is in a report? [#wat-zit-in-een-rapport]

| Source | When linked |
|------|-------------------|
| Manual payments | Calendar day of the creation date (Brussels) |
| Bank account payments | Calendar day of the payment date (Brussels) |
| Mollie | Settlement for report day D (see [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie)) |

Bank account payments **do** appear on the Tillor report for that day, but are **not** included in the accounting export (only Mollie and internal transfers).

### Yesterday without a Mollie settlement [#gisteren-zonder-mollie-settlement]

Does yesterday's report still need to be made final (or created), and has Mollie no settlement yet for yesterday or today? Then Tillor **waits** until the next working day; the report stays **draft** in the meantime. Older days without a settlement do get a report (manual/bank accounts); Mollie is linked later during synchronisation.

<Callout type="warn" title="Weekend">
Saturday and Sunday revenue often only gets a Mollie settlement on Monday morning. That belongs to the **Sunday** report (D+1 rule), not to the Monday report. See [examples on the Mollie page](/boekhouden/betalingsrapporten/betaalmethodes/mollie#voorbeelden).
</Callout>

## Examples [#voorbeelden]

| Situation | What you see |
|-----------|-------------|
| Working day, settlement the next morning | The report for **yesterday** still gets Mollie (D+1 rule) |
| Internal transfer registered today | Appears straight away on **today's draft report** and goes to the accounting |
| Mollie payment received today | Appears straight away on the draft, in the accounting as an advance on Mollie |
| Mollie payment not in the report's settlement | Moves on to the next draft when the report is made final |
| Yesterday's report still draft, no settlement | Tillor **waits** until Mollie publishes (next working day 09:00); the report stays draft |
| Report existed without Mollie | The next 09:00 run adds the settlement and payments |
| Report already had a settlement id | The id **stays**; only extra payments can still be linked |

More date examples (weekend, double settlement): [Mollie > Examples](/boekhouden/betalingsrapporten/betaalmethodes/mollie#voorbeelden).

## Opening and navigating a payment report [#betalingsrapport-openen-en-navigeren]

1. Go to **Administration > Payment Reports** (green marker **1** in the screenshot).
2. Open a report in the list.
3. On the detail page, use the arrows in the action bar on the right to go to the previous or next report.

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-reports-list.png" alt="Payment reports overview" />

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-report-detail.png" alt="Payment report detail - Send to accounting and navigation arrows" />

When you hover over an arrow you see extra context (report number, date and number of payments) of the report you are navigating to.

On the right of the detail page is the **Event Log**. There you can see when the report was created, when it was made final and whether it was sent to the accounting.

## Problems? [#problemen]

<Accordions>
<Accordion title="Yesterday's report stays Draft">
Mollie has not yet published a payout for yesterday. Tillor then waits until the next working day at 09:00. The report becomes final by itself, you do not have to do anything.
</Accordion>
<Accordion title="A payment is not on the report of the day I expected">
A payment goes on the report of the day it was received. For cash and bank transfers that is the **Date received** you entered. Change that date when registering, see [Cash and bank transfer](/betalingsverwerking/contant).
</Accordion>
<Accordion title="A Mollie payment is on the next report">
The payment was not in the payout of the report. It moves on to the next draft and stays there as an advance until Mollie pays out.
</Accordion>
<Accordion title="The report is not in my accounting">
Only Mollie payments and internal transfers are included. A report with only cash payments or bank account payments is not sent. An error when sending can be found in the **Event Log** of the report.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Accounting systems" href="/boekhouden/betalingsrapporten/boekhoudsystemen" />
  <Card title="Payment methods" href="/boekhouden/betalingsrapporten/betaalmethodes" />
</Cards>

## Terms [#begrippen]

- **Payment report**: the daily overview of payments on one calendar day, with the number `PAYR/year/day`.
- **Draft**: the report of the current day. It can still change.
- **Final**: the day is closed and the report has been sent to the accounting.
- **Advance**: a Mollie payment that Mollie has not yet paid out.
- **Settlement**: Mollie's payout to you.


# Overview (/en-GB/boekhouden)

Here you transfer payments and invoices from Tillor to your accounting software. Tillor bundles the payments per day into a payment report and sends that report on, so your bookkeeper does not have to retype anything.

<Callout type="info" title="Good to know">
- There is one payment report per calendar day. Today's report already exists as **Draft** and becomes final as soon as the day is over.
- Tillor processes the reports every working day (Monday to Saturday) at 09:00, Belgian time.
- Only Mollie payments and internal transfers go to the accounting software. Cash, bank transfers and bank accounts do appear on the report, but are not sent on.
- Mollie payments are updated every 15 minutes, bank accounts every 5 minutes.
- Mollie usually pays out the next day. The weekend often only gets a payout on Monday morning.
- Tillor bundles changes to a draft and sends it about ten seconds after the last change, and after a minute at the latest.
- A Belgian customer with a VAT number needs a Peppol ID before you can book an invoice.
</Callout>

## How does it fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  F[Geboekte factuur] --> B[Betaling]
  B --> R[Betalingsrapport van de dag]
  R -- Mollie en interne overboekingen --> X[Boekhoudsoftware]
  R -- Bankrekeningen en contant --> O[Alleen overzicht in Tillor]
```

- A payment belongs to an invoice. See [Invoices](/facturen).
- Every payment goes on the report of the day it was received.
- A Mollie payment first appears as an advance on the draft report. As soon as Mollie pays out, that advance becomes the real payout.
- The report goes to your accounting software. Which systems are supported is described under [Accounting systems](/boekhouden/betalingsrapporten/boekhoudsystemen).

## What does it do? [#wat-doet-het]

- **Payment reports**: daily overviews with the number `PAYR/YYYY/DDDD`, where DDDD is the day of the year
- **Accounting systems**: integration with Admisol, Odoo for customers and invoices (payment reports to Odoo will follow later) and [Exact Online](/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online) on request
- **Payment methods**: Mollie, bank accounts and internal transfers

**Example:** revenue from **20 May** is paid out on **21 May** and appears on report **`PAYR/2026/0140` (20 May)**. More examples: [Mollie examples](/boekhouden/betalingsrapporten/betaalmethodes/mollie#voorbeelden).

In the web app you see payments and invoices as shown below.

<DocScreenshot src="/screenshots/betalingen/payments-list.png" alt="Payments overview - All payments" />

<DocScreenshot src="/screenshots/facturen/invoices-list.png" alt="Invoices overview - All invoices" />

## See also [#zie-ook]

<Cards>
  <Card title="Payment reports" href="/boekhouden/betalingsrapporten" />
  <Card title="Accounting systems" href="/boekhouden/betalingsrapporten/boekhoudsystemen" />
  <Card title="Payment methods" href="/boekhouden/betalingsrapporten/betaalmethodes" />
  <Card title="VAT and tax" href="/boekhouden/belasting" />
  <Card title="Peppol" href="/boekhouden/peppol" />
  <Card title="Practical examples" href="/praktijk" />
</Cards>

## Terms [#begrippen]

- **Payment report**: the daily overview of payments on one calendar day.
- **Draft**: the report of the current day, which can still change.
- **Final**: a closed report that has been sent to the accounting software.
- **Payout (settlement)**: the amount Mollie puts into your bank account for a series of payments.
- **Advance on Mollie**: money Mollie still has to pay you, as it appears in the accounting.
- **General ledger**: the account number in your accounting. See [Products](/producten).
- **Peppol**: the European network for sending invoices directly to the recipient's system. See [Peppol](/boekhouden/peppol).


# Peppol (/en-GB/boekhouden/peppol)

With Peppol you send an invoice directly to the recipient's accounting system, without a PDF. Peppol is the European network for electronic invoicing. In Tillor it happens automatically: if a customer has a Peppol ID, the invoice goes along by itself after booking.

## When do you use Peppol? [#wanneer-gebruik-je-peppol]

Peppol is mandatory for:

- **Belgian B2B invoices** - sending invoices to Belgian businesses with a VAT number
- **Public contracts** - invoicing government bodies in most EU countries

For Dutch customers Peppol is optional but supported.

<Callout type="warn">
From 2026, Peppol is mandatory for all B2B invoices in Belgium. Make sure the Peppol IDs of your Belgian customers are set correctly.
</Callout>

## Setting up Peppol [#peppol-instellen]

### Peppol for your organisation [#peppol-voor-je-organisatie]

Peppol uses the **VAT number** and **address** of your organisation. Check that these details are correct in **Settings**.

On the first Peppol dispatch, Tillor automatically registers your organisation as a sender in the Peppol network.

<Callout type="info">
Contact Tillor support if Peppol is not yet available for your organisation.
</Callout>

### Setting a Peppol ID for a customer [#peppol-id-instellen-voor-een-klant]

For every customer you want to invoice through Peppol:

1. Go to *Customers > [customer] > Invoicing*
2. Open **Invoice Settings**
3. Enter the **Peppol ID**, or choose a recipient through the search icon
4. Click **Save**

<Callout type="warn">
Do you have a Belgian customer with a VAT number? Then you cannot book an invoice until a Peppol ID is set.
</Callout>

## Looking up a Peppol recipient [#een-peppol-ontvanger-opzoeken]

Do you not know a customer's Peppol ID? Use the search icon to the left of the field:

1. Go to *Customers > [customer] > Invoicing*
2. Click the search icon to the left of **Peppol ID**
3. Tillor searches automatically based on the customer's VAT number
4. Select the right recipient from the results

<Callout type="info">
Not all businesses are registered in the Peppol network. If a business is not found, you can still send the invoice by e-mail.
</Callout>

## Sending invoices through Peppol [#facturen-via-peppol-versturen]

When a customer has a Peppol ID, Tillor sends the invoice through Peppol automatically after booking:

1. Create the invoice as usual
2. Check that the customer's **Peppol ID** is set correctly
3. Check the lines and amounts on the draft invoice, then click **Book invoice**

<DocScreenshot src="/screenshots/facturen/invoice-draft-detail.png" alt="Draft invoice with Book invoice" />

4. Tillor sends the invoice automatically through the Peppol network (usually within a few minutes of booking)

### Checking the send status [#verzendstatus-controleren]

Open the booked invoice and look at **Events** in the right-hand panel. Here you can see whether the invoice was sent through Peppol, or whether sending or delivery failed.

## What happens next? [#wat-gebeurt-er-daarna]

- The invoice is sent automatically as soon as you book it. You do not have to send anything.
- An invoice that was sent through Peppol gets the label **Sent via Peppol** in the list on the customer profile.
- You can no longer set such an invoice back to draft or move it to another customer. You correct it with a credit invoice. See [Correcting an invoice](/facturen/corrigeren).
- If sending fails, you see that under **Events** on the invoice and there is a notice under <UIPath>Communication > Notifications</UIPath>. Then send the invoice by e-mail, see [Sending an invoice](/facturen/versturen).

## Problems? [#problemen]

<Accordions>
<Accordion title="The invoice cannot be booked because the customer has no Peppol ID">
The customer is Belgian and has a VAT number. Enter the Peppol ID under <UIPath>Customers > customer > Invoicing</UIPath>, **Invoice Settings**. If you do not know the ID, use the search icon to the left of the field.
</Accordion>
<Accordion title="I cannot find the recipient in the search results">
Not all businesses are connected to Peppol. Send the invoice by e-mail instead.
</Accordion>
<Accordion title="The invoice was not sent through Peppol">
Check whether the customer's Peppol ID was filled in before you booked.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Invoices" href="/facturen" description="Creating and booking invoices" />
  <Card title="VAT & Tax" href="/boekhouden/belasting" description="Validating VAT numbers" />
  <Card title="Accounting" href="/boekhouden" description="Financial overview" />
</Cards>


# Sending an invoice or reminder (/en-GB/communicatie/e-mails)

With **Send notification** you send a booked invoice to the customer. With **Send reminder** you remind the customer of an outstanding invoice. You choose e-mail, SMS, post or WhatsApp yourself, and afterwards you follow the delivery in [Notifications](/notificaties).

Tillor does not send these messages by itself when booking. You decide when the customer receives something. If you want it to happen automatically, you can do that with an [automation](/begrippen#automatisering).

Before you start:

- The invoice must be **booked**. The button does not appear on a draft invoice.
- The customer has at least an e-mail address, a phone number or a complete postal address (street, postcode and town). Otherwise you do not see **Send notification**.
- For a reminder, an amount must still be outstanding. A paid invoice does not offer **Send reminder**.
- For each channel, the matching detail must be known. Otherwise the channel is greyed out, with the message **No email address on file**, **No phone number on file** or **No postal address on file**.

## Sending an invoice [#een-factuur-versturen]

<Steps>
<Step>
### Open the invoice [#open-de-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open a booked invoice.

<DocScreenshot src="/screenshots/communicatie/invoice-send-notification-button.png" alt="Booked invoice with the Send notification button on the action bar" />
</Step>
<Step>
### Click Send notification [#klik-op-verstuur-notificatie]
The **Send notification** window opens. Choose the channels through which the customer receives the invoice.

<DocScreenshot src="/screenshots/communicatie/invoice-send-notification.png" alt="The Send notification window with E-mail, SMS and Post" />
</Step>
<Step>
### Choose the channels and click Send [#kies-de-kanalen-en-klik-op-versturen]
Tillor reports **Notification sent**. If it fails, you see **Notification not sent**.
</Step>
</Steps>

The channels work like this:

| Channel | What the customer receives |
|---|---|
| **E-mail** | On by default. The invoice is attached to the message as a PDF, sent to the e-mail address on the customer profile |
| **SMS** | A short text with the personal link to the invoice |
| **Post** | The invoice as a letter to the postal address on the customer profile. Off by default. Tillor shows an indicative postage amount per letter |
| **WhatsApp** | Appears if you have connected WhatsApp Business. If the customer's 24-hour window is closed and you have no payment method with Meta, Tillor blocks the dispatch |

## Sending a reminder [#een-aanmaning-versturen]

<Steps>
<Step>
### Open the menu next to Send notification [#open-het-menu-naast-verstuur-notificatie]
Click the arrow next to the button and choose **Send reminder**.
</Step>
<Step>
### Choose the channels [#kies-de-kanalen]
For a reminder, **SMS** is on by default if the customer has a phone number. If you choose **Post**, the customer receives a reminder letter with the invoice attached and a QR code on the letter. See [Sending an invoice](/facturen/versturen).

<DocScreenshot src="/screenshots/facturen/invoice-reminder-dialog.png" alt="Send reminder with the choice for Post and registered mail" />
</Step>
<Step>
### Confirm [#bevestig]
Click **Send**. If you also chose **Registered mail with receipt confirmation**, it says **Send with extra cost**. That option only exists if registered post is supported in the country of the postal address. Tillor charges the extra costs to your organisation.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The message appears in <UIPath>Communication > Notifications</UIPath> with channel, status and a link to the invoice. You also see it on the customer.
- E-mail and SMS start as <Status tone="info">Pending</Status> and become <Status tone="success">Sent</Status> as soon as they are delivered. The customer can read the message and click the link. You see both again in the detail window.
- For post, the status becomes <Status tone="success">Sent</Status> as soon as the postal service confirms that the letter is on its way or delivered. For post you see the postage amount at the time of sending, and for registered post also the extra amount.
- If a message is stuck for longer than 5 minutes, Tillor tries again. After 2 days without being sent it becomes <Status tone="error">Failed</Status>.
- If the message fails, the invoice stays as it was. You can always send again.

Do you want Tillor to respond by itself, for example by alerting a colleague when a reminder fails? You can create an [automation](/begrippen#automatisering) for that.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the Send notification button">
The invoice is still a draft, or the customer has no e-mail address, phone number and complete postal address. Book the invoice or add one of those details on the customer profile.
</Accordion>
<Accordion title="I do not see Send reminder in the menu">
The invoice has already been paid, or not yet booked. A reminder can only be sent for a booked invoice with an amount still outstanding.
</Accordion>
<Accordion title="A channel is greyed out with No email address on file">
The detail is missing on the customer profile. Add the e-mail address, phone number or postal address and open the window again.
</Accordion>
<Accordion title="Tillor reports Notification not sent">
Open <UIPath>Communication > Notifications</UIPath> and click the channel of the message. The error message is in the detail window. Usually the address or number is wrong. Correct it on the customer profile and send again.
</Accordion>
<Accordion title="I do not see Registered under Post">
Registered sending is only possible to postal addresses in countries where Tillor supports it. For other addresses, ordinary post remains possible.
</Accordion>
<Accordion title="The customer says they have not received anything">
Look at the status in <UIPath>Communication > Notifications</UIPath>. If the message is **Bounced**, the address does not exist. If it is **Sent**, ask the customer to check their spam. See [Notifications](/notificaties#problemen).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Notifications" href="/notificaties" description="Delivery status of sent messages" />
  <Card title="Notification types" href="/communicatie/notificatietypes" description="All kinds of messages Tillor sends" />
  <Card title="Sending an invoice" href="/facturen/versturen" description="Post, QR code and reminder letters" />
</Cards>


# Overview (/en-GB/communicatie)

Under Communication you follow everything that is said or sent between your park and your customers: phone calls, messages Tillor sends, and internal comments. Here you also decide which messages go to a customer and see whether they arrived. Conversations that customers start through chat or social media are in the [inbox](/inbox).

<DocScreenshot src="/screenshots/communicatie/providers/voys/calls-overview.png" alt="Overview of phone calls in Communication" />

<Callout type="info" title="Good to know">
- An invoice message or reminder never goes out by itself when booking. You start it, or an [automation](/begrippen#automatisering) does
- If a message is stuck for longer than 5 minutes, Tillor tries again. After 2 days without being sent it is set to **Failed**
- You can only send an SMS with organisation details during an ongoing call, from the panel at the bottom right
- A new message in the inbox appears as a card at the bottom right and disappears after about ten seconds
- Phone calls only come in after Voys is installed and the call plan points to Tillor
</Callout>

## How does it fit together? [#hoe-hangt-dit-samen]

All communication with a customer comes together on the customer profile. What goes out and what comes in runs over different channels.

```mermaid
flowchart LR
  K[Klant] -->|belt| T[Telefoongesprekken]
  K -->|chat, WhatsApp, Messenger, Instagram| I[Inbox]
  P[Park] -->|factuur of aanmaning| N[Notificaties]
  N -->|e-mail, sms, post, WhatsApp| K
  P -->|interne opmerking| O[Opmerkingen]
  T --> KP[Klantprofiel]
  I --> KP
  N --> KP
```

- **Calls** come in through your phone provider and are linked to the customer by phone number.
- **Messages from customers** via chat or social media arrive in the inbox.
- **Messages to customers** you send from an invoice. You follow the delivery under Notifications.
- **Comments** are internal. Customers do not see them.

## Components [#onderdelen]

<Cards>
  <Card title="Inbox" href="/inbox" description="WhatsApp, Messenger, Instagram and website chat in one place" />
  <Card title="Phone calls" href="/communicatie/telefoongesprekken" description="Follow up calls, listen to recordings and send details by SMS" />
  <Card title="Sending an invoice or reminder" href="/communicatie/e-mails" description="Send a message to a customer yourself" />
  <Card title="Notifications" href="/notificaties" description="View the delivery status of sent messages" />
  <Card title="Notification types" href="/communicatie/notificatietypes" description="All kinds of messages and when they go out" />
  <Card title="Comments" href="/notities" description="Internal comments on customers, invoices and other records" />
  <Card title="Providers" href="/communicatie/providers" description="Voys and Twilio: who makes the calls and who sends the texts" />
</Cards>

## Terms [#begrippen]

- **Phone provider**: the company that supplies your phone line, for example Voys.
- **Notification**: a message that Tillor sends to a customer or [user](/begrippen#gebruiker).
- **Channel**: the route a message takes, such as e-mail, SMS, post or WhatsApp.
- **Inbox**: the place where messages from customers via chat and social media arrive.
- **Comment**: an internal note on a [customer](/begrippen#klant), invoice or other record.

More terms are in the [glossary](/begrippen).


# Notification types (/en-GB/communicatie/notificatietypes)

This list shows every type of message you can come across in the [notifications overview](/notificaties), and when Tillor sends it. You see the type in the **Type** column and can filter on it with the **Type** filter. The names match the screen.

Messages to customers go by e-mail, SMS, post or WhatsApp. Messages to colleagues go by push, e-mail or phone, following that colleague's preferences. See [In-app notifications](/notificaties#meldingen-in-de-app).

<Callout type="info" title="Invoice messages do not go out by themselves">
Messages such as **New Invoice** or **Invoice Reminder** are not sent automatically by Tillor when an invoice is booked. You start them with **Send notification** or **Send reminder** on the invoice. See [Sending an invoice or reminder](/communicatie/e-mails).
</Callout>

## Invoices and payments [#facturen-en-betalingen]

| Type | When it is sent |
|---|---|
| New Invoice | To the customer, when you send an invoice. The invoice is attached to the message |
| Invoice Paid | To the customer, when an invoice has been paid |
| Invoice Reminder | To the customer, as a reminder for an outstanding invoice |
| Manual Bank Transfer Reminder | To the customer who pays by bank transfer, with the tip to use the structured reference |
| Invoice Archive | To your organisation's support address, with your bookkeeper in copy, when an invoice archive is ready |
| Peppol Invoice Send Failure | When an invoice could not be sent through Peppol |
| Failed to send invoice to accounting software | When forwarding an invoice to your accounting software fails |
| Invoice export to accounting software recovered | When that forwarding has succeeded after earlier notices |
| Failed to send payment report to accounting software | When forwarding a payment report fails |
| Reverted invoices rebooked | When reverted invoices have been rebooked automatically overnight |
| Bank payment does not settle invoice | When a bank payment has been linked to an invoice, but the invoice is still outstanding afterwards |
| Utility use well above usual, held from automatic billing | When a customer was not invoiced automatically because electricity or water use is far above the usual |
| Scheduled product price applied | To your organisation, on the day a [scheduled price](/producten/prijzen-plannen) takes effect. Old and new price are shown side by side |
| Machine start auto-refund | When an online payment for a machine start has been refunded because the machine did not start |
| Offline NFC Payments Review | When offline NFC payments could not be verified after synchronisation |
| NFC Tag Low Balance | To the customer when the balance of an NFC tag is low |

## SEPA mandates and signing [#sepa-mandaten-en-ondertekenen]

| Type | When it is sent |
|---|---|
| SEPA mandate signing request | To the customer with the link to sign the mandate, also for the reminders before the link expires |
| SEPA mandate verification code | To the customer with the code they enter on the signing page, by SMS or e-mail |
| Signed SEPA mandate copy | To the customer, as soon as the mandate is active |
| SEPA mandate revoked | To the customer, with the signed document attached once more |
| Signature request | To a signer when it is their turn, by e-mail or by SMS if there is no e-mail address |
| Signing code | To the signer with the code to sign, by SMS or e-mail |
| Signed document | To all signers with the signed PDF, as soon as the last one has signed |
| Signature declined | To the colleague who sent the request, when a signer declines |
| DPA Acceptance | Confirmation of the DPA acceptance, with the signed DPA attached |
| DPA verification code | By SMS to the responsible person with the code to accept the data processing agreement |

## Meters, controllers and access [#meters-controllers-en-toegang]

| Type | When it is sent |
|---|---|
| Meter alarm | When a meter has a new alarm |
| Meter alarm resolved | When a meter alarm has been resolved |
| Meter Removal | When meters have been removed |
| Meters needing attention | Overview of meters whose readings are missing or that have had an alarm for a long time |
| Controller offline | When a controller gives no sign of life for longer than 5 minutes |
| Controller overheating | Urgent notice when a controller gets too hot |
| Connector offline | When your park's connector no longer gives a sign of life |
| Connector back online | When the connector is reachable again |
| Connector HTTP gateway down | When the connector is still running, but cameras can no longer reach it |
| LPR camera offline | When a licence plate camera does not respond for longer than 5 minutes |
| Access point open too long | When an access point stays open longer than allowed |
| Expired license plate exit summary | Summary of vehicles with an expired access period that left while reception was closed |
| QR Access Code | To the customer with the QR code for access |
| Tablet or kiosk offline | When a tablet or kiosk gives no sign of life outside its sleep period |
| Tablet or kiosk battery low | When a tablet or kiosk is almost empty and not charging |

## Tasks, comments and inbox [#taken-opmerkingen-en-inbox]

| Type | When it is sent |
|---|---|
| Task assigned | To the colleague to whom a task has been assigned |
| Task unassigned | To the colleague from whom a task has been taken away |
| Task completed | When a task has been completed |
| Task Reminder | When a task's reminder time has been reached |
| Task deadline | When a task reaches its deadline without being completed |
| Daily task view digest | By e-mail, the daily summary of a task view you follow |
| Comment Reply | Someone has replied to a comment |
| Comment Mention | You have been mentioned in a comment |
| Comment Resolved | A comment has been marked as resolved |
| Comment reply rejected | When an e-mail reply to a comment was not posted because the sender address is not right |
| Inbox Message | When a new message arrives in the inbox |
| Urgent AI handoff | When the AI assistant hands an urgent conversation over to you |
| Website chat follow-up | To a website visitor with an unread reply, with a link to resume the conversation |

## Automations and integrations [#automatiseringen-en-integraties]

| Type | When it is sent |
|---|---|
| Automation message | Text that an automation sends to a customer |
| Automation notice | Notice that an automation sends to a colleague, by push, e-mail or both |
| Automation run failed | To the creator of an automation when a run ended with an error |
| Webhook delivery failing | When deliveries to your webhook fail and Tillor keeps trying again |
| Webhook delivery permanently failed | When Tillor could not deliver a webhook event after all attempts |
| External notification | Message that a connected system sent itself, see [External notifications](/notificaties#externe-notificaties) |

A webhook is a connection through which Tillor automatically passes an event on to another system.

## Account and organisation [#account-en-organisatie]

| Type | When it is sent |
|---|---|
| User Welcome | Welcome message for a new user |
| E-mail verification | The link to confirm an e-mail address |
| Organization invitation | Invitation for someone without a Tillor account to join your organisation |
| Organization Details | SMS to a caller with a link to your organisation's details |
| Contact Form Submission | When someone fills in the contact form |
| Holiday opening hours reminder | Reminder to fill in the opening hours for an upcoming public holiday |
| Document Deleted | To the user who deleted a document |

## Notices from the Tillor team [#meldingen-van-het-tillor-team]

These messages are meant for the Tillor team and you do not normally see them: **System Incident**, **Security alert**, **Grafana alert** and **LoRa gateway outage**.

## See also [#zie-ook]

<Cards>
  <Card title="Notifications" href="/notificaties" description="Delivery status and in-app notifications" />
  <Card title="Sending an invoice or reminder" href="/communicatie/e-mails" description="Send a message yourself" />
  <Card title="Automations" href="/automatiseringen" description="Messages from an automation" />
</Cards>


# Overview (/en-GB/communicatie/providers)

Through a phone provider such as Voys, Tillor sees who is calling and stores calls, recordings and transcriptions. You connect the provider under <UIPath>Settings > Integrations</UIPath>. Twilio is not a phone provider: it sends Tillor's SMS messages and has been set up by Tillor itself.

<DocScreenshot src="/screenshots/communicatie/providers/marketplace-overview.png" alt="Settings > Integrations" />

## Available providers [#beschikbare-providers]

<Cards>
  <Card
    title="Voys"
    href="/communicatie/providers/voys"
    description="Link incoming phone calls to customer profiles"
  />
  <Card
    title="Twilio"
    href="/communicatie/providers/twilio"
    description="SMS and WhatsApp delivery through a platform setting"
  />
  <Card title="Inbox" href="/inbox" description="Messenger and WhatsApp Business for the omnichannel inbox" />
</Cards>


# Twilio (/en-GB/communicatie/providers/twilio)

Twilio sends SMS messages on behalf of Tillor and, if set up, WhatsApp notifications. It is not a telephony provider like Voys and you do not install it yourself: Tillor has set it up for the whole platform.

## Difference from Voys [#verschil-met-voys]

| | Voys | Twilio |
|---|---|---|
| Telephony (calling, calls) | Yes | No |
| Configuration in Tillor | **Settings > Integrations** | No - platform setting |
| Visible to users | Calls, recordings, transcriptions | Sent SMS and WhatsApp notifications |

## What does Twilio do in Tillor? [#wat-doet-twilio-in-tillor]

Once Twilio is set up, Tillor uses it for things such as:

- Sending **SMS notifications** (for example payment reminders, booking confirmations and invoice notifications)
- Sending **organisation details by SMS** from **Communication > Phone Calls** (SMS button with the tooltip **Send organization details to the caller via SMS**)
- Delivering **WhatsApp notifications** when WhatsApp is set up through Twilio on the platform
- Using **SMS verification codes** when signing the data processing agreement (DPA)

You follow sent SMS and WhatsApp notifications in **Communication > Notifications**:

<DocScreenshot src="/screenshots/notificaties/notifications-overview.png" alt="Notifications overview - delivery status of messages" />

<Callout type="info">
You do not set up Twilio yourself in Tillor. Ask your platform administrator or Tillor support for the right integration for your environment.
</Callout>

## No installation under Integrations [#geen-installatie-in-integraties]

Unlike Voys, you will **not** find Twilio under **Settings > Integrations**. The integration is managed by the administrator of the Tillor environment.

## See also [#zie-ook]

<Cards>
  <Card
    title="Voys Telephony"
    href="/communicatie/providers/voys"
    description="Telephony integration for calls"
  />
  <Card
    title="Phone calls"
    href="/communicatie/telefoongesprekken"
    description="Sending organisation details by SMS"
  />
</Cards>


# Voys Telephony (/en-GB/communicatie/providers/voys)

With the Voys integration, Tillor sees who is calling and shows the customer details straight away. Calls, recordings and transcripts then end up under [Phone Calls](/communicatie/telefoongesprekken). Voys is a business phone provider.

Before you start:

- You need an active Voys VoIP account, and access to the call plan settings in Voys.
- You need the **Manage integrations** permission.
- The caller's phone number must be on the customer profile or on a contact person, otherwise Tillor cannot link the call to a customer.

<DocScreenshot src="/screenshots/communicatie/providers/voys/incoming-call.png" alt="Incoming call on the dashboard" />

## Set up Voys [#voys-instellen]

1. Go to **Settings** (sidebar under **Support**)

<DocScreenshot src="/screenshots/communicatie/providers/voys/marketplace-nav.png" alt="Navigation to Settings" />

2. Choose **Integrations** and open **Voys** in the list
3. On the detail page, enter your Voys details (`username`, `password`, `client_uuid`, `token`) and click **Install**

You need an active Voys VoIP account.

<DocScreenshot src="/screenshots/communicatie/providers/voys/marketplace-voys.png" alt="Settings > Integrations - Voys in the list" />

<Callout type="info">
After installation and configuration, Tillor links calls to customers automatically when the phone number matches a customer or contact.
</Callout>

## Find the URLs for Voys [#urls-voor-voys-terugvinden]

Tillor and Voys talk to each other through addresses (URLs). At some steps Voys asks Tillor for an answer, for example whether you are open. That answer is **ACK** (yes, continue) or **NAK** (no, follow the other path). A webhook is an address that Voys calls during a call.


For webhooks, caller name lookup and access codes, you use the URLs that Tillor generates for you.

1. Go to **Settings > Integrations** and open **Voys**
2. After installation, the **URLs to configure** block appears on the detail page under **Settings** - copy the right URL for each purpose

Among other things, you will find:

- **Conversation notifications** - webhook URL for call events
- **Webhook for Caller Lookup** - URL for caller name lookup in your Voys call plan
- **XML Phonebook** - URL for VoIP phones to fetch the phone book
- **Access codes** - URL for operating the access point (barrier, gate or door) through the call plan
- **Opening hours webhook** - ACK when Tillor is open, NAK when Tillor is closed
- **Caller allowed webhook** - ACK when the caller may be put through, NAK when the caller must go to voicemail
- **Routing webhook** - ACK with a destination, NAK when no destination is set

In the Voys call plan, use the same variables as listed in Tillor (such as `{callerid}`, `{did}`, `{callername}`, `{callid}` and `{code}`).

<DocScreenshot src="/screenshots/communicatie/providers/voys/config-urls-dialog.png" alt="Voys detail - URLs to configure on the page" />

## Configure call notifications in Voys [#gespreksnotificaties-in-voys-configureren]

1. In Voys, open the [Call notifications](https://freedom.voys.nl/redirect/CallNotification) module
2. Click **Add**
3. For package/service, choose **Custom**
4. Paste the Tillor URL from **Conversation notifications**
5. Save

Voys documentation:

- [Call notifications](https://help.voys.nl/gespreksnotificaties)

## Configure caller names (caller lookup) in the call plan [#bellernamen-caller-lookup-in-call-plan-configureren]

For caller name lookup, you use a webhook step in the call plan in Voys.

1. In Tillor, open the **Webhook for Caller Lookup** URL (on **Settings > Integrations > Voys**, under **URLs to configure**) and copy it
2. In Voys, open the [Webhooks](https://help.voys.nl/webhooks) module and create a webhook with this URL template
3. Activate that webhook in your call plan through the webhook step
4. In the URL template, use the variables that Voys supports (`{callerid}`, `{did}`, `{callername}` and, if needed, `{code}`)
5. In the webhook routing, set **Variable caller name** so that the returned name is shown on handsets

The opening hours and routing webhooks do not do a caller name lookup. Use this separate step for that.

More background:

- [Webhooks](https://help.voys.nl/webhooks)
- [What are call notifications (difference from webhooks)](https://help.voys.nl/gespreksnotificaties)

## Opening hours and destinations in the call plan [#openingsuren-en-bestemmingen-in-het-belplan]

Tillor is the source for opening hours, holidays and public holiday exceptions. Voys no longer needs to know that calendar itself.

1. On **Settings > Integrations > Voys**, choose the Voys handset for **open** and optionally for **closed**
2. Copy **Opening hours webhook** or **Routing webhook** from **URLs to configure**
3. In Voys, create a [webhook](https://help.voys.nl/webhooks) with that URL template
4. Put that webhook as a step in the call plan, **above** any menus
5. Leave **Use menu** off

Two patterns:

- **Opening hours webhook** - `status=ACK` follows the **HTTP and menu succeeded** path (open), `status=NAK` follows **HTTP or menu failed** (closed). If an open destination is set, it is included with ACK as `destination`.
- **Routing webhook** - Tillor chooses the destination. In the succeeded step, set **Variable final destination**. ACK + `destination` when there is a destination, otherwise NAK.

On an error or timeout, Voys takes the failed path. Treat that as closed.

Voys documentation: [Webhooks](https://help.voys.nl/webhooks).

## Send callers to voicemail automatically [#bellers-automatisch-naar-voicemail-sturen]

With the **Caller allowed webhook**, you let Voys decide per caller whether a call is put through. Tillor checks whether the caller's number belongs to a customer who has automatic voicemail switched on.

First set up the call plan:

1. Copy **Caller allowed webhook** from **URLs to configure** on **Settings > Integrations > Voys**
2. In Voys, create a [webhook](https://help.voys.nl/webhooks) with that URL template
3. Put that webhook as a step in the call plan, **above** the steps that put the call through
4. Leave **Use menu** off
5. Send the **HTTP and menu succeeded** path on to your normal routing and the **HTTP or menu failed** path to voicemail
6. On **Settings > Integrations > Voys**, under **Call routing**, tick **Auto voicemail in Voys**

As long as that is off, you will not see **Send calls to voicemail** on the customer profile.

Then switch on automatic voicemail per customer:

1. Open the customer profile and go to the **Communication** tab
2. In **Communication settings**, tick the **Send calls to voicemail** option
3. Click **Save**

This is how the answer works:

- **ACK** - the caller may go through. This also applies to unknown numbers and to callers with a hidden number.
- **NAK** - the number belongs to a customer with automatic voicemail. Voys follows the failed path.

Tillor compares the caller's number with the phone number on the customer profile, regardless of spaces or country code notation. Phone numbers of contact persons do not count.

<Callout type="warn">
On an error or timeout, Voys also takes the failed path. All callers then temporarily go to voicemail, not only the blocked ones. So use a voicemail destination where you check messages regularly.
</Callout>

This webhook does not look at opening hours. Combine it with the opening hours or routing webhook by putting both as separate steps in the call plan.

Voys documentation: [Webhooks](https://help.voys.nl/webhooks).

## Fixed routing per caller [#vaste-routering-per-beller]

The same **Routing webhook** can send a caller straight to a specific Voys handset, extension or phone number. That only applies to customers for whom you have chosen a destination, and only when **Static call routing in Voys** is on.

1. Put the **Routing webhook** in the call plan, as with opening hours
2. In the succeeded step, set **Variable final destination**
3. On **Settings > Integrations > Voys**, under **Call routing**, tick **Static call routing in Voys**

As long as that is off, you will not see **Static call routing** on the customer profile. The webhook then only uses the handset for open or closed.

Then set the destination per customer:

1. Open the customer profile and go to the **Communication** tab
2. Under **Static call routing**, choose a Voys handset, or **Other** for a phone number or extension (for example 411)
3. Choose **None** to switch off the fixed routing
4. Click **Save**

This is how the routing webhook chooses the destination:

- If there is a fixed destination for this caller, that is the `destination`.
- Otherwise, `destination` is the Voys handset for open or closed.
- **NAK** - there is no fixed destination and no handset for the current state. This also applies to unknown numbers and to callers with a hidden number, as long as there is no open or closed handset.

Tillor compares the caller's number with the phone number on the customer profile, regardless of spaces or country code notation. Phone numbers of contact persons do not count.

On an error or timeout, Voys takes the failed path.

Voys documentation: [Webhooks](https://help.voys.nl/webhooks).

## What happens next? [#wat-gebeurt-er-daarna]

- Every call that comes in or goes out is listed in <UIPath>Communication > Phone Calls</UIPath>, with the customer attached if the number matches. See [Phone Calls](/communicatie/telefoongesprekken).
- For an incoming call, the caller appears as a card at the bottom right in Tillor, with the customer details.
- Recordings and transcripts follow as soon as the call has ended, if call recording is switched on in your Voys account.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the URLs to configure block">
The block only appears after installation. First click **Install** on the Voys detail page.
</Accordion>
<Accordion title="No calls are coming in to Tillor">
Voys only forwards calls once the call notifications module uses the **Conversation notifications** URL from Tillor. Check in Voys that the URL is there and that it comes from the **URLs to configure** block.
</Accordion>
<Accordion title="The caller name does not appear on the handset">
Check that the webhook for caller name lookup is in the call plan and that **Variable caller name** is set in the succeeded step. The opening hours and routing webhooks do not look up names.
</Accordion>
<Accordion title="I do not see Send calls to voicemail on the customer profile">
First tick **Auto voicemail in Voys** under <UIPath>Settings > Integrations > Voys</UIPath>, at **Call routing**. Only then does the option appear on the customer's **Communication** tab. The same goes for **Static call routing**.
</Accordion>
<Accordion title="All callers suddenly go to voicemail">
On an error or timeout of a webhook, Voys takes the failed path. Check that Tillor is reachable and that the URL in the webhook is still correct. See the warning at [Send callers to voicemail automatically](#bellers-automatisch-naar-voicemail-sturen).
</Accordion>
<Accordion title="A call does not belong to a customer">
Tillor compares the number with the phone number on the customer profile. Numbers of contact persons count for linking calls, but not for voicemail and fixed routing.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card
    title="Phone Calls"
    href="/communicatie/telefoongesprekken"
    description="Call actions such as organisation details by SMS"
  />
  <Card title="Customer Management" href="/klantenbeheer" description="Customer profiles and contact details" />
  <Card title="Twilio" href="/communicatie/providers/twilio" description="How SMS messages are sent" />
</Cards>


# Phone Calls (/en-GB/communicatie/telefoongesprekken)

Under <UIPath>Communication > Phone Calls</UIPath> you will find every call that comes in or goes out through your phone provider, with the customer attached if Tillor recognises the number. You use the page to follow up on calls and, during a call in progress, to send your organisation's details to the caller by SMS.

Before you start:

- Calls only appear after you have installed and set up [Voys](/communicatie/providers/voys). Without the integration, the list stays empty.
- Recordings and transcripts only exist if call recording is switched on in your Voys account.
- The SMS button in a call in progress only works if SMS sending is set up for your environment. See [Twilio](/communicatie/providers/twilio).

## View calls [#gesprekken-bekijken]

<DocScreenshot src="/screenshots/communicatie/providers/voys/calls-overview.png" alt="Overview of phone calls" />

In the **All Calls** table you see the following for each call:

| Column | What you see |
|---|---|
| **Direction** | **Inbound** or **Outbound** |
| **Started At** | Date and time |
| **From** and **To** | The phone numbers |
| **Duration** | The length of the call, once it has ended |
| **Customer** | The linked customer, or a name that Voys passed on (not verified) if no customer is linked |
| **Status** | Where the call currently stands |

Tillor links a call to a customer based on the phone number. If the number does not belong to a customer yet, add it to the customer profile or to a contact person. New calls are then linked automatically.

A call goes through these statuses:

| Status | Meaning |
|---|---|
| <Status tone="info">Created</Status> | The call has just started |
| <Status tone="info">Ringing</Status> | The phone is ringing |
| <Status tone="warning">Answered</Status> | Someone has picked up |
| <Status tone="warning">In Progress</Status> | The call is in progress |
| <Status tone="warning">Warm Transfer</Status> and <Status tone="warning">Cold Transfer</Status> | The call has been transferred, with or without an announcement |
| <Status>Hung Up</Status> and <Status>Ended</Status> | The call is over |
| <Status tone="error">Failed</Status> | The call was not established |

## Send organisation details by SMS [#organisatiegegevens-via-sms-versturen]

A caller asks for your address or opening hours? Send them by SMS within a few seconds, while the call is in progress.

<Steps>
<Step>
### Wait until the call is in progress [#wacht-tot-het-gesprek-loopt]
The action is on the panel with active calls at the bottom right, not in the list. The call must have the status **In Progress**. On a phone, first tap the phone icon at the top right.
</Step>
<Step>
### Expand the call [#klap-het-gesprek-uit]
If the call is collapsed, expand it.
</Step>
<Step>
### Click the message icon [#klik-op-het-berichtenpictogram]
The tooltip says **Send organization details to the caller via SMS**.
</Step>
<Step>
### Choose the language [#kies-de-taal]
Tillor marks the language it recognises for the caller with *(detected)*. Choose the language of the SMS.
</Step>
</Steps>

The caller receives a short link to a public page with your organisation's details. If your organisation's address is filled in, there are also route buttons for **Waze**, **Google Maps** and **Apple Maps**. The email button on that page already has a subject and message text, with the number and time of the call in it when they are known. The website link gets tracking tags, so you can measure how many callers click through.

## Recordings and transcripts [#opnames-en-transcripties]

<Steps>
<Step>
### Open the call [#open-het-gesprek]
In the list, click **Transcription** next to the call. The **Call Details** window opens.
</Step>
<Step>
### Choose a tab [#kies-een-tabblad]
On **Recording**, the call plays in your browser. On **Transcription** you find the written-out text per speaker, and on **Summary** a short summary.
</Step>
</Steps>

Tillor creates the transcript and summary itself as soon as the call has finished and a recording exists. That takes a little while. For a call without a recording, there are no tabs.

<Callout type="warn">
Call recordings can contain privacy-sensitive information. Make sure you comply with privacy legislation (GDPR) when recording calls, and inform callers that calls are recorded.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- Once a call has ended, it is in the list with its duration, the customer and, if there is a recording, a transcript and summary.
- An SMS sent with organisation details is listed in <UIPath>Communication > Notifications</UIPath> with the type **Organization Details**.

## Problems? [#problemen]

<Accordions>
<Accordion title="The list of calls is empty">
Check that Voys is installed under <UIPath>Settings > Integrations</UIPath> and that the call notifications in Voys point to the URL from Tillor. See [Voys Telephony](/communicatie/providers/voys).
</Accordion>
<Accordion title="A call does not belong to a customer">
Tillor compares the caller's number with the phone number on the customer profile or on a contact person. Add the number and new calls will be linked. Calls that have already come in stay as they were.
</Accordion>
<Accordion title="I cannot find the SMS button">
The button is only on the panel with active calls at the bottom right, and only while the call has the status **In Progress**. It is not in the list on this page.
</Accordion>
<Accordion title="I do not see a Recording tab">
Voys did not record the call. Switch on call recording in your Voys account. Earlier calls cannot be recorded afterwards.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Voys Telephony" href="/communicatie/providers/voys" description="Install Voys and set up the call plan" />
  <Card title="Twilio" href="/communicatie/providers/twilio" description="How SMS messages are sent" />
  <Card title="Notifications" href="/notificaties" description="Delivery status of sent SMS messages" />
</Cards>


# Connector (/en-GB/connector)

The Tillor Connector is a small box on your park's network. It connects Tillor to the devices on site: receipt printers, barriers, access controllers and ID readers. Without a connector, Tillor cannot operate those devices. If it is switched off, printing and operating barriers from Tillor do not work. How to carry on in that case is described under [Problems](#problemen).

Tillor supplies the connector preconfigured and monitors it remotely. You do not need to install or update anything.

<Callout type="info" title="Good to know">
- Every organisation has one connector. If you manage several parks, each park (organisation) gets its own box.
- The connector reports to Tillor every 15 seconds.
- If Tillor hears nothing from it for 3 minutes, the Tillor team is notified automatically.
- Tillor installs updates itself, without you doing anything.
- The connector sets up a secure, outgoing connection itself. You do not need to open any ports on your router.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

The connector sits between Tillor on the internet and the devices on your own network. Tillor sends an instruction to the connector, and the connector carries it out on the right device. In the other direction, the connector reports what happened, for example a licence plate that was read.

```mermaid
flowchart LR
  T[Tillor] <-->|beveiligde verbinding via internet| C[Connector in je park]
  C --> P[Bonnenprinter]
  C --> S[Slagboom of toegangscontroller]
  C --> I[Identiteitslezer]
```

For example:

- You print a receipt or label. Tillor sends it to the connector, and the connector puts it on your printer.
- You give a customer an access method. Tillor sends the change through the connector to the access controllers, see [Access Control](/toegangscontrole#hoe-hangt-dit-samen).
- A guest scans an ID card at check-in. The connector passes the scan on to Tillor, see [Identity document scans](/identiteitsscans).

## What Tillor does for you [#wat-tillor-voor-je-doet]

- **Delivery**: the box arrives preconfigured for your organisation.
- **Installation and linking**: we connect your printers, barriers and scanners during start-up.
- **Updates**: new versions are installed automatically, without interruption.
- **Monitoring**: Tillor sees whether the connector is connected and reports an outage itself.

## What you need yourself [#wat-je-zelf-nodig-hebt]

- A power socket near your network equipment
- A network cable to your router or switch, on the same network as your printers and barriers
- A stable internet connection

## Connected devices [#gekoppelde-apparaten]

- **Printers**: see [Printer](/printer) for setting up and using them.
- **Barriers, gates and access controllers**: see [Access Control](/toegangscontrole).
- **ID readers**: see [Identity document scans](/identiteitsscans) for creating customers from a scan and retention periods.

<Callout type="info" title="For the technical reader">
On your park's network, you can view the connector's status at `http://[adres-van-de-connector]:3000/`. You will see the connection to Tillor, the print queue and the licence plates read most recently. Tillor support gives you the address during installation. More about the protocol is under [MQTT](/ontwikkelaars/mqtt).
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="The connector is not connected">
Check that the box is receiving power and that the network cable is firmly connected. Check whether the internet in your park works. Then unplug the box briefly and plug it back in. If the problem persists, contact Tillor support. We usually see an outage ourselves already.
</Accordion>
<Accordion title="Printing or operating a barrier does not work">
First check the status of the connector, see the technical tip above. Check that the device is switched on and on the same network. If the connector is connected and the device is reachable but nothing happens, contact support.
</Accordion>
<Accordion title="New access methods do not reach the gate">
Look under **Controller Operations** on the Access Control page. If an instruction stays on **Pending**, the connector is offline.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Connector**: the box in your park that connects Tillor to your devices.
- **Access controller**: a box at a barrier that reads tags and QR codes.
- **Managed solution**: Tillor supplies, configures and maintains the box for you.

More explanation is in the [glossary](/begrippen).

## See also [#zie-ook]

<Cards>
  <Card title="Controllers" href="/controllers" description="Tag readers at showers, doors and charging points" />
  <Card title="Printer" href="/printer" description="Setting up and using printers" />
  <Card title="Access Control" href="/toegangscontrole" description="Barriers and access methods" />
  <Card title="Identity document scans" href="/identiteitsscans" description="Scanning ID cards at check-in" />
</Cards>


# Documents (/en-GB/documenten)

With document management, you keep files on a customer, such as insurance policies, ID cards, contracts, permits and other attachments. Files that do not belong to anyone yet are in the central document list until you link them to a customer. Start at [Documents on a customer](#documenten-bij-een-klant) or at [The central document list](#de-centrale-documentenlijst).

<Callout type="info" title="Good to know">
- A file can be 250 MB at most.
- You can upload PDF, Word, Outlook messages (.msg), Excel, PowerPoint, images (JPEG, PNG, GIF) and text files.
- Tillor converts images to PDF after uploading. The other file types stay as they are, with a PDF preview next to them.
- When a document is deleted, you receive a copy as an attachment at your email address, if the file could be secured.
- A PDF that belongs to a signature request, and the signed PDF, can be archived but not deleted.
- An archived document is kept, but is no longer among the active documents.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  U[Upload of e-mail] --> C[Centrale documentenlijst]
  C -->|Koppelen aan klant| K[Documenten van de klant]
  K --> S[Ondertekenverzoek]
  S --> O[Ondertekende PDF bij de klant]
  M[SEPA-mandaat] --> K
```

A document is in one place: either in the central list, or on a customer. If you link it to a customer, it disappears from the central list. Signed PDFs and signed mandates automatically end up in the customer's documents.

## Documents on a customer [#documenten-bij-een-klant]

### View documents [#documenten-bekijken]

1. Go to <UIPath>Customers > Overview</UIPath> and open the customer's profile.
2. Click the **Documents** tab.
3. You see this customer's documents, divided into **Active** and **Archived**.
4. Click a document (or the eye icon) to view it on the right in the **Preview**. With the download icon, you save it.

### Edit, move or archive a document [#een-document-bewerken-verplaatsen-of-archiveren]

The **…** menu next to a document contains **Edit**, **Move to customer**, **Download**, **Archive** (or **Unarchive**) and **Delete**.

### Delete a document [#een-document-verwijderen]

Before you start: a document that belongs to a signature request cannot be deleted. Archive it instead.

<Steps>
<Step>
### Choose Delete [#kies-verwijderen]
Choose **Delete** in the **…** menu next to the document.
</Step>
<Step>
### Confirm [#bevestig]
In the dialog, confirm with **Delete**, or cancel with **Cancel**. Deleting cannot be undone.

<DocScreenshot src="/screenshots/documenten/document-delete-dialog.png" alt="Confirmation dialog for deleting a document" />
</Step>
</Steps>

After deleting, you receive a message at your account email address with the deleted document as an attachment, so you usually have a copy at hand.

### Have a document signed [#een-document-laten-ondertekenen]

Under a customer's documents are the **Signature requests**. With **Request signatures**, you have a PDF signed online by the customer, a contact person, a colleague or an external party. The signed PDF is added to the documents as **[title] (signed)**, with the type **Signed agreement** if the original PDF had no type. See [Signatures](/handtekeningen).

## The central document list [#de-centrale-documentenlijst]

Besides documents on customers, Tillor has a central list. Files that are not linked to a customer yet appear here, for example documents that arrive by email. Go to <UIPath>Administration > Documents</UIPath>.

<DocScreenshot src="/screenshots/documenten/documents-upload.png" alt="Central document list with upload area" />

### Upload a document [#een-document-uploaden]

<Tabs items={["Drag or choose", "By email"]}>
<Tab value="Drag or choose">
Drag a file to the upload area, or click **Select file**. The file is saved automatically and appears as a new item in the list.
</Tab>
<Tab value="By email">
In the upload area there is a special email address. Send the file as an attachment to that address, and it appears in the central list by itself.
</Tab>
</Tabs>

### Link a document to a customer [#een-document-koppelen-aan-een-klant]

Every document in the central list has an edit form and a preview panel.

<Steps>
<Step>
### Find the document [#zoek-het-document]
Go to <UIPath>Administration > Documents</UIPath> and scroll to the document.
</Step>
<Step>
### Fill in the fields [#vul-de-velden-in]
- **Document Name**: the name of the document.
- **Assign to Customer**: the customer this document belongs to (optional).
- **Document type**: for example **Insurance policy**, **Insurance payment proof**, **Identity card**, **SEPA mandate**, **Signed agreement** or **Other** (optional).
- **Insurance Expiry Date**: the date on which an insurance policy or permit expires. This field only appears for document types that can have an expiry date.
- **Notes**: free notes on the document (optional).
</Step>
<Step>
### Save [#sla-op]
Click **Save Changes**.
</Step>
</Steps>

### What happens next? [#wat-gebeurt-er-daarna]

- The document disappears from the central list and is on that customer's **Documents** tab.
- If you filled in an **Insurance Expiry Date**, you see it as a label on the document.

## AI suggestions for documents [#ai-suggesties-bij-documenten]

When you upload a PDF, Tillor analyses the content in the background. If Tillor recognises a name that matches a customer in your administration, a suggestion button appears next to **Assign to Customer** with the customer's name and a percentage that shows how sure Tillor is. A suggestion can also appear for an insurance expiry date.

Click the button to accept the suggestion, or choose a different customer yourself. A suggestion is always a proposal. Click **Save Changes** to make your choice final.

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot delete a document">
If the document belongs to a signature request, as the original PDF or as the signed PDF, Tillor refuses to delete it, because it is evidence. Archive it with **Archive** in the **…** menu.
</Accordion>
<Accordion title="Tillor says: Archiving failed">
The message is **The document could not be archived.** Try again. The same goes for **Restore failed** with **Unarchive**.
</Accordion>
<Accordion title="Tillor says: Update failed">
Your changes to **Document Name**, customer, type or notes were not saved. Check the form and click **Save Changes** again.
</Accordion>
<Accordion title="Tillor says: Download failed">
The document could not be downloaded. Try again.
</Accordion>
<Accordion title="The Insurance Expiry Date field is missing">
That field only appears for document types that can have an expiry date, such as **Insurance policy**. First choose the right type under **Document type**.
</Accordion>
<Accordion title="My file is not accepted">
Check the file type (PDF, Word, Outlook message, Excel, PowerPoint, JPEG, PNG, GIF or text) and the size (250 MB at most).
</Accordion>
<Accordion title="The document is no longer in the central list">
As soon as a document is linked to a customer, it is only on that customer under **Documents**. If it is in the archive, you will find it under **Archived**.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Document type**: the kind of document, for example **Insurance policy** or **Identity card**.
- **Archived**: a document that is kept but is no longer among the active documents.
- **Central document list**: files that are not linked to a customer yet.
- **Signature request**: an instruction to have a PDF signed. See [signature request](/begrippen#ondertekenverzoek).
- **Customer**: the record in Tillor that a document hangs on. See [customer](/begrippen#klant).

## See also [#zie-ook]

<Cards>
  <Card title="Customer Management" href="/klantenbeheer" />
  <Card title="Signatures" href="/handtekeningen" />
</Cards>


# Overview (/en-GB/eigen-velden)

With custom fields, you add fields to a record yourself. Think of a gas bottle deposit number on a customer, a surcharge on a terrain or an expected arrival time on a reservation. The field appears in that record's form, just like the fields Tillor brings itself.

You manage them under <UIPath>Settings > Custom fields</UIPath>.

<DocScreenshot src="/screenshots/eigen-velden/custom-fields-list.png" alt="Settings > Custom fields with the Customers tab and the list of fields" />

<Callout type="info" title="Good to know">
- You cannot change a field's type and key after creating it
- Text: 1,000 characters at most by default, Long text 10,000. A pick list has 200 options at most
- A group of fields has 30 subfields at most. Repeating rows: 100 rows at most by default, never more than 500
- Files: 20 per field at most by default (never more than 50), each 50 MB at most
- A field that disappears because of a condition is cleared when the record is saved
- A deleted field disappears from the forms. The values that were filled in do stay on the records
- All limits per type are under [Field types and settings](/eigen-velden/veldtypes)
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

You create a field once, and it then appears everywhere that kind of record is filled in.

```mermaid
flowchart LR
  L[Keuzelijst met opties] -->|gebruikt door| V[Eigen veld van het type Keuze]
  V -->|staat in het formulier van| R[Klant, terrein, bezetting, taak en andere records]
  T[Toegang: wie mag zien en bewerken] --> V
  R -->|waarden komen terug in| E[Exports, filters en automatiseringen]
```

- **Pick lists** you create separately from the fields. If you change an option, it is correct in every field that uses the list.
- **A field** belongs to one kind of record. The type and key are fixed.
- **Access** you arrange per field. Anyone who may not see a field never gets to see the value, not even in exports or automations.

## Where you can add custom fields [#waar-kun-je-eigen-velden-toevoegen]

Every kind of record has its own tab. The number of fields is shown after the name.

| Tab | Record |
|---|---|
| **Customers** | Customer profile |
| **Terrains** | Terrain |
| **Occupations** | Occupation |
| **Meters** | Meter |
| **Tasks** | Task |
| **Products** | Product |
| **Documents** | Document |
| **Reservations** | Reservation |
| **Access methods** | Access method |

The **Pick lists** tab has no records. There you create lists of options that you reuse in choice fields.

## What you can do with them [#wat-je-ermee-kunt]

- Add a field of a certain type, such as text, number, amount, date, choice or file. See [Field types and settings](/eigen-velden/veldtypes)
- Place the field in the form among the existing fields, or only show it when another value matches
- Make the field required, optionally only under a condition
- Decide who may see the field and who may edit it. See [Visibility and access](/eigen-velden/zichtbaarheid-en-toegang)

The values are available in the export of customers and terrains and in automations. An automation can also fill a custom field with the **Set custom field** step.

## Who can use it [#wie-kan-het-gebruiken]

<Callout type="info" title="Managing requires a permission">
Creating, changing, rearranging and deleting fields is possible with the **Manage custom fields** permission. Anyone without it can open the page if they may view settings, but the buttons are then disabled.
Anyone who may see and edit a field can fill it in on a record.
</Callout>

## Parts [#onderdelen]

<Cards>
  <Card
    title="Create a custom field"
    href="/eigen-velden/veld-aanmaken"
    description="Add, place and adjust a field step by step"
  />
  <Card
    title="Pick lists"
    href="/eigen-velden/keuzelijsten"
    description="Define options for the Choice and Multiple choice types"
  />
  <Card
    title="Field types and settings"
    href="/eigen-velden/veldtypes"
    description="Which settings and limits apply per type"
  />
  <Card
    title="Visibility and access"
    href="/eigen-velden/zichtbaarheid-en-toegang"
    description="Where the values appear and who may see or edit them"
  />
</Cards>

## Terms [#begrippen]

- **[Custom field](/begrippen#eigen-veld)**: an extra field that you add to a record yourself
- **Label**: the name that colleagues see above the input field
- **Key**: the fixed name of the field, for example `gasMeterNumber`. You see it in the list and it is used in exports and filters
- **Type**: what kind of value the field stores
- **[Pick list](/begrippen#keuzelijst)**: a list of options that you use in several choice fields

More terms are in the [glossary](/begrippen). A worked example is under [Practical examples](/praktijk).


# Create pick lists (/en-GB/eigen-velden/keuzelijsten)

A field of the type **Choice** or **Multiple choice** needs a pick list. You create the list once and use it in as many fields as you like. If you change an option, it is correct everywhere straight away.

<Requires permission="Manage custom fields" />

<Steps>
<Step>
### Open the Pick lists tab [#open-het-tabblad-keuzelijsten]
Go to <UIPath>Settings > Custom fields</UIPath> and click **Pick lists**. Every list shows its options with colour and how many fields use it.

<DocScreenshot src="/screenshots/eigen-velden/custom-fields-enums.png" alt="The Pick lists tab with the Contract type list" />
</Step>
<Step>
### Create a list [#maak-een-lijst-aan]
Click **New pick list**. Fill in a **Name** and optionally a **Description**. Tillor creates a **Key** itself.
</Step>
<Step>
### Add options [#voeg-opties-toe]
Click **Add option** and fill in the **Label**, for example *Seasonal*. Choose a colour with the colour dot. A list needs at least one option.

<DocScreenshot src="/screenshots/eigen-velden/custom-fields-enum-dialog.png" alt="New pick list dialog" />
</Step>
<Step>
### Save [#sla-op]
Click **Save**. Then choose the list when creating a field of the type **Choice** or **Multiple choice**.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The list is available when you create a field of the type **Choice** or **Multiple choice**.
- If you later change an option's label or colour, it is correct straight away in every field that uses the list.
- An option's **Value** is fixed as soon as it has been used on a record.

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot delete a list">
A list that is still used in a field cannot be deleted. Tillor says that the list is still used by a field. First remove the list from those fields or delete those fields.
</Accordion>
<Accordion title="My choice field says Create a pick list first">
No list exists yet. Create one on the **Pick lists** tab and then choose it in the field.
</Accordion>
<Accordion title="I cannot save the list">
A list needs at least one option and 200 at most. Add an option with **Add option**.
</Accordion>
</Accordions>


# Create a custom field (/en-GB/eigen-velden/veld-aanmaken)

With a custom field, you store information that Tillor does not know itself, such as a gas bottle deposit number on a customer. You create it in a few minutes, and on the right of the page you immediately see how colleagues will get the field. Afterwards you fill it in on the record itself, see [Visibility and access](/eigen-velden/zichtbaarheid-en-toegang).

Before you start:

- You need the **Manage custom fields** permission. Without that permission, the **New field** button is grey.
- If the field needs a choice, first create a [pick list](/eigen-velden/keuzelijsten). Otherwise it says **Create a pick list first**.
- Choose the type carefully: you cannot change it afterwards.

<Requires permission="Manage custom fields" />

<Steps>
<Step>
### Open Custom fields and choose the tab [#open-eigen-velden-en-kies-het-tabblad]
Go to <UIPath>Settings > Custom fields</UIPath> and open the tab of the record the field belongs to, for example **Customers**. Click **New field**.

If the tab is still empty, you see a few suggestions under **Quick start**, such as **Number of dogs** for customers. Click a suggestion to open the form already filled in. Suggestions with a pick list first ask for a list. See [Pick lists](/eigen-velden/keuzelijsten).
</Step>
<Step>
### Fill in the field [#vul-het-veld-in]
Under **1. Field**, you choose the kind of record at **Applies to**, give the field a **Label** and choose the **Type**. Every type card has a short explanation.

Tillor creates a **Key** from your label itself. Under **3. Key** you can change it with **Change** before you save.

<DocScreenshot src="/screenshots/eigen-velden/field-new-form.png" alt="New custom field with the type cards, the settings and the preview on the right" />
</Step>
<Step>
### Fine-tune the field [#stel-het-veld-af]
Under **2. Settings** are the options that belong to the chosen type. See [Field types and settings](/eigen-velden/veldtypes). You can also choose:

- **Width**: **Half** or **Full width** in the form
- **Position in form**: leave the field at the bottom (**Default section (bottom)**), or choose an existing field of the form and put the field **Before** or **After** that field
- **Required**: the record cannot be saved while the field is empty
- **Visibility**: only show the field when a condition is met
- **Required when**: only make the field required when a condition is met
- **Validation rules**: compare the value with another field, or check it with an expression
- **Help text**: a short explanation under the input field
</Step>
<Step>
### Decide who may access it [#bepaal-wie-erbij-mag]
Under **4. Access**, by default everyone may see and edit the field. Click **Restrict** to change that. See [Visibility and access](/eigen-velden/zichtbaarheid-en-toegang).
</Step>
<Step>
### Save the field [#sla-het-veld-op]
Click **Save**. Tillor says **Field saved** and takes you back to the list. The field is immediately in the record's form.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The field is immediately in the record's form, at the place you chose.
- Existing records still have an empty value. If the field is required, a colleague has to fill it in before saving such a record again.
- The values are included in the export of customers and terrains and are available in automations.
- Who may see or edit the field, you arrange under **4. Access**.

## Position and conditions [#plaats-en-voorwaarden]

With **Position in form**, you put a field with the fields it belongs with, instead of at the bottom. With **Visibility**, you only show a field when another value calls for it. In this example, **Winter storage** only appears for a terrain with the **Contract type** Seasonal, directly after **Description**.

<DocScreenshot src="/screenshots/eigen-velden/field-edit-conditions.png" alt="Edit field with Position in form and a condition at Visibility and Required when" />

A condition consists of one or more rules. At **Condition type**, you choose **Rules** or **Expression**. The expression is meant for complicated cases and requires a bit of code. For most fields, rules are enough.

<Callout type="info" title="A hidden field is cleared">
If a field disappears because the condition no longer holds, Tillor erases the value when the record is saved. If the field comes back, it is empty. A field that is required under a condition is only required while it is visible.
</Callout>

## Edit, move or delete a field [#een-veld-bewerken-verplaatsen-of-verwijderen]

In the list, every field has four buttons.

| Button | What it does |
|---|---|
| **Move up** and **Move down** | Changes the order of the fields in the form |
| **Edit field** | Opens the field. The type, the key and the record the field belongs to are then fixed |
| **Delete** | Deletes the field after a confirmation |

A deleted field disappears from the forms. The values that were filled in do stay on the records, but are no longer shown or edited.

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot click New field">
The button is disabled without the **Manage custom fields** permission. Ask an administrator to grant the permission.
</Accordion>
<Accordion title="I want to change the type or key of an existing field">
That is not possible. Create a new field with the right type and then delete the old field. Tillor does not carry over values from the old field.
</Accordion>
<Accordion title="My field is not where I expect it">
Check at **Position in form** whether you chose a field. With **Default section (bottom)**, the field comes after the form's standard fields. If it has a condition at **Visibility**, it is only there when that condition holds.
</Accordion>
</Accordions>


# Field types and settings (/en-GB/eigen-velden/veldtypes)

When you create a field, you choose a type. You cannot change the type afterwards. Under **2. Settings** are that type's options. All options are optional, unless stated otherwise below.

For almost every type, you can also fill in an **Error message**. It replaces the default message when a value is not right. With **Placeholder**, you decide what appears in the empty input field.

## Text and Long text [#tekst-en-lange-tekst]

**Text** is one line, **Long text** several lines.

| Setting | What it does |
|---|---|
| **Minimum length** and **Maximum length** | The number of characters. Without a maximum, 1,000 characters apply for Text and 10,000 for Long text |
| **Format** | **Any text**, **Email address**, **Phone number**, **Web address**, **IBAN**, **Postcode**, **Digits only** or **Custom pattern** |
| **Pattern (regular expression)** | With **Custom pattern**. The whole value must match. Tillor refuses patterns with nested repetitions or backreferences and patterns longer than 200 characters |

## Number and Amount [#getal-en-bedrag]

**Amount** uses your organisation's currency.

| Setting | Applies to | What it does |
|---|---|---|
| **Minimum** and **Maximum** | Number, Amount | Lower limit and upper limit |
| **Whole numbers only** | Number | No decimals allowed |
| **Display** | Number, only for whole numbers | **Input field** or **Counter (− / +)** with buttons |
| **Step** | Number | The value must be the minimum (or 0) plus a whole number of steps |
| **Maximum decimals** | Number | Limits the decimals |

## Yes / no [#ja--nee]

An on/off switch. With **Must be checked**, the record can only be saved with the box ticked. Handy for consent.

## Date [#datum]

| Setting | What it does |
|---|---|
| **Earliest date** and **Latest date** | Fixed limits |
| **Not in the past** and **Not in the future** | Compared with today in your organisation's time zone |
| **Within days of today** | At most this many days before or after today |

## Choice and Multiple choice [#keuze-en-meerkeuze]

You choose a [pick list](/eigen-velden/keuzelijsten). **Choice** stores one option, **Multiple choice** several. With Multiple choice, you set **Minimum selected** and **Maximum selected**. A list has 200 options at most.

## Link to record [#koppeling-naar-record]

The field points to another record in Tillor.

| Setting | What it does |
|---|---|
| **Links to** | Customer, Terrain, Occupation, Meter, Task, Invoice, Reservation, Payment report, Phone call, Contact, Product, Meter cabinet, Payment, Document, NFC tag or Access method |
| **Several records** | Allow more than one linked record. You can then also set a minimum and maximum |
| **Display** | **Picker** or **Dropdown** (one searchable list) |
| **Only this customer's records** | Limits the options to records of the customer you are editing. Only for Contact, Invoice, Reservation, Occupation, Payment, Document, NFC tag and Access method |
| **Only the terrain's records** | Limits the options to the terrain's meters: for an occupation the terrain of that occupation, for a terrain the terrain itself. Only for Meter. You cannot save a meter from another terrain |
| **Filter options** | Optional TypeScript that decides per option whether it appears in the list, see [Filter options](#opties-filteren). For Contact, Product, Meter cabinet, Payment, Document, NFC tag, Access method, Invoice, Reservation, Occupation, Meter and Terrain |

If a linked record is deleted later, the field shows **Deleted**.

If there are at least 50 records to choose from, you first type 2 characters to search. If there are fewer, such as the meters of one terrain, you see them all straight away.

### Filter options [#opties-filteren]

With **Filter options**, you decide yourself which records the field offers. You write TypeScript, like the [rate formula](/terreinen#tariefformule), which Tillor runs for every option. If it returns `true`, the option appears in the list; otherwise it does not.

In the filter, you read fields with curly braces. The **Variable** menu shows what is available, including custom fields:

| Variable | What it is |
|-----------|------------|
| `{option.…}` | The record you could choose, for example `{option.type}` or `{option.terrainId}` for a meter |
| `{occupation.…}`, `{terrain.…}`, … | The record you are editing, under the name of its type, with `customFields` for its own fields |

Example: only electricity meters of the occupation's terrain.

```ts
return {option.type} === "ELECTRICITY" && {option.terrainId} === {occupation.terrainId};
```

### Custom labels [#eigen-labels]

The same filter can also decide what an option is called in the list. What you return decides the result:

| You return | Result |
|----------------|-----------|
| `true` | The option is in the list under its own name |
| `false`, `null` or an empty text | The option is not in the list |
| A text | The option is in the list under that text |
| `{ label, group }` | The option gets that label and goes under the heading `group`. Both are optional |

Example: only meters from ICY and Hydrodigit, with the type added and grouped per supplier.

```ts
if (!["ICY", "TILLOR_HYDRODIGIT"].includes({option.provider})) return false;
return { label: {option.name} + " · " + {option.type}, group: {option.provider} };
```

The label applies in the picker and on the chosen chips in the form. In places that only show the value, such as the detail page or an export, the record's own name is shown.

**Insert example** under the field gives a starting point. A filter that does not compile cannot be saved; the message under the field says what is wrong.

The filter does not only limit the list. If you still choose a record through the API or an old form that the filter leaves out, Tillor refuses to save it and names the field. Automations and imports are not checked, just as they may also fill in hidden fields.

## Group of fields [#groep-velden]

A fixed set of subfields that appear together in the form, such as **Dogs** and **Other animals** under **Animals**.

| Setting | What it does |
|---|---|
| **Add sub-field** | Every subfield has a label, type and its own settings. Click **More** for the key, width and conditions. A group can have 30 subfields at most |
| **Display** | **Card** (with a border) or **Inline** (the fields continue in the form) |
| **Columns** | 1 up to and including 4 |
| **Width in the group** | Per subfield how many columns it spans |

## Repeating rows [#herhalende-rijen]

A table to which you add rows with **Add row**, for example several vehicles. You set the subfields as with a group. With **Minimum rows** and **Maximum rows**, you limit the list. Without a maximum, 100 rows apply, and more than 500 is not possible.

A group or repeating row may contain one more level of group or repeating row, no deeper.

## Files [#bestanden]

For documents and photos. A file that you upload can only be opened by whoever may see the field.

| Setting | What it does |
|---|---|
| **Several files** | Allow more than one file |
| **Minimum files** and **Maximum files** | Without a maximum, 20 files apply, and more than 50 is not possible |
| **Maximum size per file (MB)** | 50 MB per file at most, even if you want a higher value |
| **Allowed file types** | **Any file**, **Images**, **PDF**, **Office documents**, or your own extension such as `.dwg` or a MIME type such as `application/zip` |

Tillor checks the type from the file's content, not only from its name.

## JSON [#json]

Meant for structured data that an integration supplies. Colleagues rarely fill this in on the form. With **Maximum size (KB)**, you set a limit, 64 KB by default and 256 KB at most.

## Settings for every type [#instellingen-voor-elk-type]

| Setting | What it does |
|---|---|
| **Encrypt this value** | Stores the value encrypted. An encrypted field cannot be searched, filtered or sorted and is not available as a variable in automations. Only for top-level fields, so not for subfields. All custom fields are stored encrypted anyway, whether you switch this on or not |
| **API only** | Hides the field in forms and detail views. An integration fills it through the API. Such a field cannot be required |
| **API only, read-only** | Does show the field, but disabled, so colleagues see the value but cannot change it |
| **Validation rules** | Compare a date, number or amount with another field (**Before**, **On or before**, **After**, **On or after**, with an offset in days, weeks or months), or check the value with an expression. 10 rules per field at most |

A changed limit does not apply retroactively. A value that you do not change does not block saving the record, even if it no longer meets the new rule.


# Visibility and access (/en-GB/eigen-velden/zichtbaarheid-en-toegang)

A custom field appears in the form of the record it belongs to. By default, everyone with access to that record can see and fill in the field. You can restrict that per field.

## Where you see the values [#waar-je-de-waarden-ziet]

You fill in custom fields in the same place as the other details of the record.

| Record | Where |
|---|---|
| Customer | The **Customer Details** block on the customer profile |
| Terrain, meter, occupation, reservation, product, document, access method | The form to create or edit the record |
| Task | The task window. You save changes with **Save fields** |

A field appears in the position you chose under **Position in form**. If you made no choice, it appears after the standard fields.

<DocScreenshot src="/screenshots/eigen-velden/customer-custom-fields.png" alt="The customer profile with custom fields such as Dogs, Arrival date and Gas cylinder deposit number between the standard fields" />

If a field is required, you cannot save the record while it is empty. A field with **Visibility** only appears when the condition is met.

Custom fields are also included in the export of customers and terrains and you can use them in automations.

## Who can see or edit a field [#wie-mag-een-veld-zien-of-bewerken]

Open the field under <UIPath>Settings > Custom fields</UIPath> and go to **4. Access**. Click **Restrict**.

<Requires permission="Manage custom fields" />

<DocScreenshot src="/screenshots/eigen-velden/field-edit-access.png" alt="Edit field with Who can see this field and Who can edit this field" />

You have two blocks.

| Block | What it does |
|---|---|
| **Who can see this field** | If you leave it empty, every member can see it. Anyone who may not see it never sees the value, not even in exports or in automations they edit |
| **Who can edit this field** | If you leave it empty, everyone who sees the field can also edit it. Others see it read-only |

In each block you choose a **colleague or group** and/or a **permission**. If someone matches one of the chosen colleagues, groups or permissions, they have access. You can only edit a field if you are also allowed to see it.

In the list, such a field gets the label **Restricted**. Hover over it for the explanation: only certain colleagues, groups or permissions may see or edit this field.

<Callout type="warn" title="A hidden field is not a secured field">
The **Visibility** option (a condition) only hides a field in the form. Anyone who may see the field can still find the value. Use **Who can see this field** if nobody else may read it.
</Callout>

## Who can manage fields [#wie-mag-velden-beheren]

Creating, changing, reordering and deleting fields and managing choice lists requires the **Manage custom fields** permission. How you grant permissions is described in [Inviting users and granting permissions](/gebruikers/gebruikers-en-rechten). The **Custom fields** page is visible to anyone who may view or edit settings, or who has this permission. Without the permission you only see the fields you may read, and **New field**, edit and delete are disabled.

## Problems? [#problemen]

<Accordions>
<Accordion title="A colleague does not see a field">
Check under **Who can see this field** whether that colleague, their group or one of their permissions is selected. If the field is an **API only** field, it does not appear in forms.
</Accordion>
<Accordion title="A colleague cannot change a field">
Look under **Who can edit this field**. If colleagues, groups or permissions are selected there, others are limited to reading. If someone tries to change the value anyway, Tillor refuses.
</Accordion>
</Accordions>


# Creating and editing an invoice (/en-GB/facturen/aanmaken-en-bewerken)

A new invoice is always a draft: you create it on the customer profile and fill in the lines. As long as it is a draft, you can add, change, move and delete lines. After that you [book it](/facturen/boeken).

Before you start:

- The customer already exists in Tillor. See [Customer management](/klantenbeheer).
- For products with a terrain or occupation, the customer has an occupation on that terrain. Without an occupation you create a quote that you cannot book.

## Creating an invoice [#een-factuur-aanmaken]

You create invoices on the customer profile, not from <UIPath>Administration > Invoices</UIPath>.

<Steps>
<Step>
### Open the customer [#open-de-klant]
Go to <UIPath>Customers > Overview</UIPath> and open the customer's profile.
</Step>
<Step>
### Create the invoice [#maak-de-factuur-aan]
In the **Invoices** block, click **New Invoice**. Tillor creates a draft invoice and opens the invoice page straight away.

<DocScreenshot src="/screenshots/klanten/customer-new-invoice.png" alt="New invoice from the customer profile" />
</Step>
</Steps>

The invoice gets a temporary draft number. The final invoice number, the invoice date and the due date only appear when you [book it](/facturen/boeken).

## Adding and changing lines [#regels-toevoegen-en-aanpassen]

The invoice page has a table with the invoice lines. At the bottom is an empty row where you start a new line.

<Steps>
<Step>
### Choose a product or type a description [#kies-een-product-of-typ-een-omschrijving]
Choose a **Product** from the list and Tillor fills in the **Description** and the price. You can also type a description yourself.
</Step>
<Step>
### Enter quantity and price [#vul-aantal-en-prijs-in]
Adjust the **Quantity** and the **Price (incl. VAT)** per unit where needed. The **Total** of the line is calculated automatically. If the setting for VAT per line is on for your organisation, you also choose the VAT rate.
</Step>
<Step>
### Add a note (optional) [#voeg-een-notitie-toe-optioneel]
Below the table you can fill in a **Note (Optional)**. That text appears on the invoice and is visible to the customer.
</Step>
</Steps>

Changes are saved automatically almost immediately. You can also click **Save changes**, or **Cancel** to undo unsaved changes.

### Reordering or deleting lines [#regels-herschikken-of-verwijderen]

- Drag a line by the handle to its left to change the order.
- Click the cross to the right of a line to delete it.

On the **Events** timeline next to the invoice you see what was changed and when, with the before and after of the fields and lines.

## Lines with an action [#regels-met-een-actie]

If the chosen product has an action on the invoice line, extra input appears below the line. Which actions a product has is set on the product itself. See [Product actions](/producten/productacties).

| Action | What you fill in on the invoice |
|-------|-----------------------------|
| **Top up NFC Tag** | The tag to be topped up. After payment, Tillor adds the amount to the tag's balance. |
| **Period** | Start and end date, and for a product with a terrain also the **Terrain** (in a list or **Choose on the map**). |
| **Extend Occupation Period** | The terrain for which you extend the occupation, plus start and end date. |
| **Request contact details** | The customer's email address and phone number. If they are required, you cannot book without them. |
| **Create access method** | The type of access method and optionally a licence plate or PIN code. |
| **Show alert** | Nothing. You only see an alert with the text set on the product. |
| **Prevent booking** | Nothing. The invoice cannot be booked as long as the line is on it. |

### Choosing the period and terrain [#periode-en-terrein-kiezen]

For a line with **Period** you choose a start and end date. Below it you see the number of days and the **Quantity** that Tillor charges. If the period does not fit a week or month of the product exactly, Tillor rounds up and **Rounded up** is shown. With the **Pro rata** checkbox you charge a partial week or month proportionally instead. That checkbox only appears for products with a weekly or monthly period.

If the product needs a terrain, you first choose the period and then the **Terrain**.

When booking, Tillor creates the reservation. A card then appears on the line with reservation number, status, terrain and dates. Whether the customer is checked in straight away depends on the product: with **Check in on booking** it happens when booking, with **Check in on payment** only once the invoice is paid. An advance payment only holds the terrain.

### Extending an occupation [#een-bezetting-verlengen]

With **Extend Occupation Period** you invoice a period for one of the customer's occupations, for example pitch fees.

<Steps>
<Step>
### Choose the terrain [#kies-het-terrein]
Under **Select active occupation** choose the terrain. The list shows the customer's active occupations.
</Step>
<Step>
### Choose the period [#kies-de-periode]
Choose the **Start date**. Tillor then immediately opens the calendar for the **End date**. Below the dates you see until when the occupation is currently invoiced and how many days and what quantity the line covers.
</Step>
<Step>
### Set the rounding [#stel-het-afronden-in]
The **Round to next period boundary** checkbox is on by default. The line then ends at the next period boundary of the rental frequency, so the customer follows the same cycle in time. With the checkbox off, the line lasts exactly one period from the start date.
</Step>
</Steps>

The line gets a description in the form **Product name | Terrain name | Period**. The end date counts as the last day, and a half period is also charged for half.

If the occupation already has a **Paid until** date and rounding is on, the new line starts the day after. If **Paid until** is still empty, you choose the start date yourself and Tillor calculates the end date up to the next period boundary. What happens with **Paid until** and **Invoiced until** after booking and payment is described under [Occupations](/bezettingen).

Two extra checkboxes help in exceptional situations:

- **Show all terrains (offer)** lets you choose any terrain to make a quote. If the customer does not have an occupation on that terrain, you cannot book the invoice. Users with the **Invoice corrections** permission can still book such an invoice, see [Booking an invoice](/facturen/boeken#problemen).
- **Mark as credit (refund)** turns the line into a refund. The quantity becomes negative and the period runs from today until **Paid until**. With **Round to period boundary** you round that to a period boundary.

## What happens next? [#wat-gebeurt-er-daarna]

- Changes are saved automatically almost immediately. The **Events** timeline shows who changed what.
- Nothing is sent to the customer and nothing changes about occupations or tags. That only happens when you [book](/facturen/boeken) and when payment is made.
- A draft with a **Prevent booking** line cannot be booked.
- You delete a draft with **Delete invoice** in the actions menu.

## Problems? [#problemen]

<Accordions>
<Accordion title="I can no longer change the lines">
Only draft invoices can be edited. Under certain conditions you can set a booked invoice back to draft, see [Correcting an invoice](/facturen/corrigeren#terugzetten-naar-concept).
</Accordion>
<Accordion title="A line with Top up NFC Tag shows no tags">
The customer has no available tag. Link an NFC tag to the customer first. See [NFC](/nfc).
</Accordion>
<Accordion title="I do not see the New Invoice button">
The button is on the customer profile in the **Invoices** block, not on the invoice list under **Administration**.
</Accordion>
<Accordion title="The customer is not in the Select active occupation list">
For **Extend Occupation Period**, the list only shows the customer's active occupations. Create an occupation first, see [Occupations](/bezettingen), or use **Show all terrains (offer)** for a quote.
</Accordion>
</Accordions>

## Next [#verder]

<Cards>
  <Card title="Booking an invoice" href="/facturen/boeken" />
  <Card title="Products" href="/producten" description="Set up actions on invoice lines" />
</Cards>


# Printing, downloading or sharing an invoice (/en-GB/facturen/afdrukken-en-downloaden)

With **Print** you print an invoice, save it as a PDF or send it to a printer. The button is on every invoice page, including drafts. The arrow next to it opens a menu with the other options. You create a link for the customer under [Sharing a personal link](#een-persoonlijke-link-delen).

Before you start: for the printer options, a Tillor Connector must be running for your organisation. Without a connector those options are greyed out.

## Printing or saving [#afdrukken-of-opslaan]

| Option | What it does |
|-------|--------------|
| **Print** | Opens the print window of your browser. You can also use the shortcut Ctrl+P (Cmd+P on a Mac). |
| **Open in new window** | Shows the PDF in a new window. |
| **Download PDF** | Saves the invoice as a PDF file. |
| **Send to A4 printer** | Sends the invoice to your connected A4 printer. |
| **Send to receipt printer** | Sends the invoice to your connected receipt printer. |

The two printer options are greyed out as long as no Tillor Connector is active for your organisation. How you set up printers is described under [Printer](/printer).

## Showing the invoice on a tablet [#de-factuur-tonen-op-een-tablet]

If there is a tablet at the desk that shows customer documents, you can have the invoice appear there. Open the three dots at the top right of the invoice page and choose **Preview on iPad**. For a cash payment, the same button is also in the payment window.

## Sharing a personal link [#een-persoonlijke-link-delen]

For a booked invoice you can create a link that the customer can open to view the invoice and, if anything is still outstanding, pay online.

<Steps>
<Step>
### Open the actions menu [#open-het-actiemenu]
Click the three dots at the top right of the invoice page and choose **Personal URL**.
</Step>
<Step>
### Share the link [#deel-de-link]
Tillor copies the link to your clipboard and shows the message **URL generated**. Paste it into a message or email to the customer.
</Step>
</Steps>

<DocScreenshot src="/screenshots/facturen/invoice-actions-menu.png" alt="Invoice actions menu - Personal URL, Copy invoice, Reverse invoice" />

The actions menu contains more options. See [Correcting an invoice](/facturen/corrigeren) for copying, reversing and recalculating an invoice.

## What happens next? [#wat-gebeurt-er-daarna]

- Printing, downloading and sending to the printer change nothing about the invoice.
- With **Preview on iPad** the customer sees the invoice on the tablet. The invoice timeline shows that the PDF was sent to the tablet.
- The personal link has no expiry date. The customer sees the outstanding amount there and can pay online. See [Letting a customer pay online](/betalingsverwerking/online).
- Products can also print automatically on payment. See [Product actions](/producten/productacties#thermisch-printen-en-a4-printen).

## Problems? [#problemen]

<Accordions>
<Accordion title="Send to A4 printer is greyed out">
There is no active Tillor Connector for your organisation. Check the connection and the printer settings, see [Printer](/printer).
</Accordion>
<Accordion title="Personal URL is missing">
That option is only in the actions menu of a booked invoice.
</Accordion>
<Accordion title="Printing fails">
Tillor then shows a message with the reason, for example that paper or toner has run out. Fix that and try again.
</Accordion>
</Accordions>

## Next [#verder]

<Cards>
  <Card title="Printer" href="/printer" description="Set up printers and print automatically" />
  <Card title="Sending an invoice" href="/facturen/versturen" />
</Cards>


# Registering a payment (/en-GB/facturen/betalingen-registreren)

On a booked invoice with an outstanding amount you make a payment or record one, for example a card payment, cash or a direct debit. The amount, the payment status and the **Payments** list next to the invoice are then updated. All methods are also described under [Payment processing](/betalingsverwerking).

Before you start:

- The invoice is booked and an amount is still outstanding. Otherwise **Make payment** is missing.
- For **Terminal**, Mollie is connected. For **SEPA Mandate**, the customer has an active mandate. Otherwise the method is not in the list or is greyed out.

## Making a payment [#een-betaling-uitvoeren]

<Steps>
<Step>
### Open the booked invoice [#open-de-geboekte-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open a booked invoice. The **Make payment** button is there as long as an amount is outstanding.

<DocScreenshot src="/screenshots/facturen/invoice-booked-actions.png" alt="Booked invoice - Make payment" />
</Step>
<Step>
### Choose the payment method [#kies-de-betaalmethode]
Click **Make payment** and choose a **Payment method**.

<DocScreenshot src="/screenshots/betalingen/payment-dialog-cash.png" alt="Payment dialog - payment method and amount" />

| Method | Use it for |
|---------|-----------------|
| **Terminal** | A card payment. You choose a payment terminal and Tillor sends the payment to it. See [Terminal](/betalingsverwerking/terminal). |
| **Internal Transfer** | Moving the amount to another booked invoice of the same customer (**Target invoice**). See [Internal transfer](/betalingsverwerking/interne-overboeking). |
| **Cash** | Recording a cash payment. See [Cash](/betalingsverwerking/contant). |
| **Bank Transfer** | Recording a bank transfer you have received. |
| **SEPA Mandate** | An automatic direct debit via an active **Mandate** of the customer. See [Mandate](/betalingsverwerking/mandaat). |
| **Others** | Another form of payment, such as a cheque. It is under **More payment methods** and is only visible if you have turned it on. A description is then required. |

**Terminal** and **SEPA Mandate** only appear if they are available for your organisation. **SEPA Mandate** is greyed out as long as the customer has no active mandate, and does not exist for credit invoices.
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in]
The **Amount** defaults to the full outstanding amount. Type a different amount or use the **25%**, **50%**, **75%** and **100%** buttons. The amount may not be higher than what is outstanding.
</Step>
<Step>
### Fill in the extra fields [#vul-de-extra-velden-in]
For **Cash**, **Bank Transfer** and **Others** you optionally fill in the **Date received** (not in the future) and a **Note**. For a direct debit you choose the **Mandate** and optionally a **Delay (days)**, where 0 sends immediately.

If you choose **Bank Transfer** and the customer has an email address, you can tick **Send structured communication reminder**. The customer then receives an email with the tip to use the structured communication for future payments.
</Step>
<Step>
### Submit the payment [#voer-de-betaling-uit]
Click **Submit payment**.

<DocScreenshot src="/screenshots/facturen/invoice-payments.png" alt="Payments on the invoice" />
</Step>
</Steps>

For **Cash** there is also a **Preview on iPad** button to show the invoice to the customer on a linked tablet.

## Maximum amounts [#maximumbedragen]

A cash payment may not be higher than the **Cash payment maximum** under <UIPath>Support > Settings > Payments</UIPath> (2999 euros by default). For a direct debit, the amount may not exceed the maximum of the mandate.

## Linking an existing payment [#een-bestaande-betaling-koppelen]

If a payment or bank transaction that belongs to this invoice has already come in, you link it instead of creating a new one.

<Requires permission="Assign payment" />

<Steps>
<Step>
### Open the actions menu [#open-het-actiemenu]
Click the three dots at the top right of the invoice page and choose **Assign payment**.
</Step>
<Step>
### Choose the payment [#kies-de-betaling]
In the window, choose a payment or group. The **Payment groups**, **Card & online payments** and **Bank transactions** tabs show what is available. At the top are suggestions that match the outstanding amount.
</Step>
<Step>
### Link [#koppel]
Click **Assign payment**, **Assign group** or **Assign bank transaction**, depending on what you chose.
</Step>
</Steps>

For bank transactions you also need the **View bank transactions** permission.

## Creating a link for a part-payment [#een-link-voor-een-deelbetaling-maken]

If the customer only wants to pay part of the outstanding amount, you create a payment link for an amount you choose. You can do that on any booked invoice with an outstanding amount.

<Steps>
<Step>
### Open the actions menu [#open-het-actiemenu-1]
Click the three dots next to **Send notification** and choose **Part-payment link**.

<DocScreenshot src="/screenshots/facturen/invoice-part-payment-menu.png" alt="Actions menu of an invoice with Part-payment link" />
</Step>
<Step>
### Enter the amount [#vul-het-bedrag-in-1]
Under **Amount**, type what the customer may pay. The amount must be greater than 0 and may not be higher than what is still outstanding.
</Step>
<Step>
### Create the link [#maak-de-link]
Click **Create and copy link**. Tillor copies the link to your clipboard and shows it under **Payment link**. With the copy button next to it you copy it again.

<DocScreenshot src="/screenshots/facturen/invoice-part-payment-dialog.png" alt="Part-payment link dialog with amount and payment link" />
</Step>
</Steps>

Send the link to the customer yourself, for example by email or chat. The customer opens the normal payment page of the invoice, but it now only asks for your amount, with a message that it is a part-payment of the amount still outstanding. The customer then pays in the way they choose on [the payment page](/betalingsverwerking/online).

The link stays valid, but never asks for more than what is outstanding at that moment. If part has been paid in the meantime, the payment page adjusts accordingly. After a payment the invoice shows <Status tone="warning">Partially</Status> until the full amount has come in.

## What happens next? [#wat-gebeurt-er-daarna]

- The outstanding amount decreases and the payment status changes: <Status tone="warning">Partially</Status> as long as something is outstanding, <Status tone="success">Paid</Status> once everything has come in.
- For a direct debit or card payment, the invoice first shows <Status tone="info">Pending</Status> until the money has definitively come in.
- If a line has a payment action, Tillor carries it out as soon as the invoice is paid. Think of topping up an NFC tag, extending **Paid until** of an occupation or printing a receipt. See [How does this fit together?](/producten#hoe-hangt-dit-samen).
- The payment appears on the payment report of the day. See [Payment reports](/boekhouden/betalingsrapporten).

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Make payment">
The invoice must be booked and an amount must be outstanding. You cannot pay on a draft invoice.
</Accordion>
<Accordion title="I do not see Part-payment link">
The invoice must be booked and an amount must still be outstanding.
</Accordion>
<Accordion title="SEPA Mandate is greyed out">
The customer has no active mandate. Set that up in the customer details, see [Mandate](/betalingsverwerking/mandaat).
</Accordion>
<Accordion title="I cannot choose Others">
That payment method is off by default. Turn on **Show "Others" payment method** under <UIPath>Support > Settings > Payments</UIPath>.
</Accordion>
<Accordion title="The invoice shows Pending">
The payment has started, for example a direct debit, but the money has not definitively come in yet. Once the payment is processed, the status changes to **Paid**. See [Statuses](/facturen/statussen).
</Accordion>
</Accordions>

## Next [#verder]

<Cards>
  <Card title="Payment processing" href="/betalingsverwerking" description="All payment methods in detail" />
  <Card title="Statuses" href="/facturen/statussen" />
</Cards>


# Booking an invoice (/en-GB/facturen/boeken)

Booking turns a draft into a final invoice with its own invoice number. Only then can you [send](/facturen/versturen) the invoice and [have it paid](/facturen/betalingen-registreren). So check the lines before you book, because a booked invoice can no longer be changed freely.

Before you start:

- The invoice has at least one line, or a total that is not zero.
- Lines with **Period** or **Extend Occupation Period** have a start and end date.
- If a line has an action that asks for details, they are filled in. Think of **Request contact details** or **Create access method**.
- For a Belgian customer with a VAT number, a Peppol ID is filled in. See [Peppol](/boekhouden/peppol).

If something is wrong, **Book invoice** is greyed out. Hover over the button to read why. See also [Problems?](#problemen).

## Booking an invoice [#een-factuur-boeken]

<Steps>
<Step>
### Open the draft invoice [#open-de-conceptfactuur]
Go to <UIPath>Administration > Invoices</UIPath> and open an invoice with status <Status>Draft</Status>, for example via the **Drafts** list.
</Step>
<Step>
### Check the invoice [#controleer-de-factuur]
Review the lines and the note.

<DocScreenshot src="/screenshots/facturen/invoice-draft-detail.png" alt="Draft invoice - lines and Book invoice" />
</Step>
<Step>
### Click Book invoice [#klik-op-boek-factuur]
The invoice gets a sequential invoice number. Tillor confirms that the invoice has been booked.
</Step>
</Steps>

## What changes? [#wat-verandert-er]

This is what an invoice looks like before and after booking. They are two different example invoices, but you can see the difference in number, status and buttons.

**Before booking**: a temporary draft number and the **Book invoice** button.

<DocScreenshot src="/screenshots/facturen/invoice-before-title.png" alt="Title of a draft invoice with the draft number CON/2026/0001" />

<DocScreenshot src="/screenshots/facturen/invoice-before-toolbar.png" alt="Buttons of a draft invoice: Book invoice and Print" />

**After booking**: a final invoice number, a payment status and the **Make payment** and **Send notification** buttons.

<DocScreenshot src="/screenshots/facturen/invoice-after-title.png" alt="Title of a booked invoice with number INV/2026/0001 and the payment status Partially" />

<DocScreenshot src="/screenshots/facturen/invoice-after-toolbar.png" alt="Buttons of a booked invoice: Make payment, Print and Send notification" />

## What happens next? [#wat-gebeurt-er-daarna]

- The **invoice date** is the day of booking. The **due date** is that day plus your organisation's **Default due date (days)**, 7 days by default. You change that under <UIPath>Support > Settings > Invoicing</UIPath>.
- If the total is not a multiple of 5 cents, Tillor adds a **Rounding** line itself.
- If the invoice has a negative total, it becomes a **Credit Invoice**.
- If the customer has a Peppol ID, Tillor sends the invoice automatically via Peppol. See [Peppol](/boekhouden/peppol).
- Lines with **Extend Occupation Period** set **Invoiced until** of the occupation to the end of the line. **Paid until** only follows on payment. See [How does this fit together?](/producten#hoe-hangt-dit-samen).
- Lines with **Period** and **Ask for a site** create a reservation. Whether the customer is checked in straight away depends on the product.
- If a direct-debit mandate is linked, Tillor immediately creates an outstanding payment. The bank is charged two days after booking.
- The customer receives nothing automatically. You send the notification yourself, see [Sending an invoice](/facturen/versturen).
- Do you still want to change something? Within 7 days and as long as nothing has been sent, you set the invoice [back to draft](/facturen/corrigeren#terugzetten-naar-concept).

## Choosing a different payment term [#een-andere-betaaltermijn-kiezen]

If the due date differs from your default, you do not need to set that up in advance.

<Steps>
<Step>
### Open the dropdown menu [#open-het-keuzemenu]
Click the arrow next to **Book invoice** and choose **Custom payment terms…**.
</Step>
<Step>
### Choose the term [#kies-de-termijn]
Under **Payment terms** choose an option, from **Due on invoice date** to **Net 60 days**. You immediately see the **Estimated due date**.
</Step>
<Step>
### Book [#boek]
Click **Book invoice**.
</Step>
</Steps>

## Forwarding to your accounting [#doorsturen-naar-je-boekhouding]

Forwarding to your accounting software normally happens by itself. If you want to start it again, for example after an error, you can do that per invoice.

<Requires permission="Send to Accounting" />

Open the booked invoice, click the three dots at the top right and choose **Send to accounting software**. Which systems are available is described under [Accounting](/boekhouden). [Exact Online](/boekhouden/betalingsrapporten/boekhoudsystemen/exact-online) is available on request.

## Problems? [#problemen]

<Accordions>
<Accordion title="Book invoice is greyed out">
Hover over the button. Tillor names the reason. The most common ones are below.
</Accordion>
<Accordion title="This draft invoice contains a Prevent booking line">
The product on that line does not allow booking. Delete the line or choose a different product.
</Accordion>
<Accordion title="Fill in a start and end date on every line with Period or an extended occupation period">
A line with **Period** or **Extend Occupation Period** is missing a date. Fill in the start and end date.
</Accordion>
<Accordion title="Add at least one line or a total amount other than zero">
Add a line, or make sure the total is not zero.
</Accordion>
<Accordion title="Fill in the required contact details, or choose an access method type">
On lines with **Request contact details**, fill in the required fields. On lines with **Create access method**, choose a type, and for licence plate recognition also the licence plate.
</Accordion>
<Accordion title="This invoice extends a terrain that the customer does not have an occupation on (quote)">
Such an invoice is a quote and you cannot book it. First have the customer take the terrain into occupation. If you have the **Invoice corrections** permission, you can use the arrow next to **Book invoice** to choose **Force book**. The occupation is then only extended once the customer occupies the terrain.
</Accordion>
<Accordion title="The invoice amount exceeds the maximum of the linked mandate">
The invoice amount may not exceed the maximum amount of the linked mandate. Change the mandate under **Direct-debit mandate** in the **Invoice Information** next to the invoice, or lower the amount. See [SEPA mandate](/betalingsverwerking/mandaat).
</Accordion>
<Accordion title="This invoice brings the customer's balance below zero">
A product with a guarded ledger (for example a deposit) may not bring the customer's balance below zero. If you have the **Override ledger balance** permission, you can still book with a justification. See [Guarding the customer's balance](/producten/product-aanmaken#het-saldo-van-de-klant-bewaken).
</Accordion>
<Accordion title="Invoice cannot be booked because the customer has no Peppol ID">
For a Belgian customer with a VAT number, a Peppol ID must be known. Open <UIPath>Customers > customer > Invoicing</UIPath>, go to **Invoice Settings** and fill in the ID. See [Peppol](/boekhouden/peppol).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Sending an invoice" href="/facturen/versturen" />
  <Card title="Registering payments" href="/facturen/betalingen-registreren" />
  <Card title="Correcting an invoice" href="/facturen/corrigeren" description="If you still want to change something after booking" />
</Cards>


# Correcting an invoice (/en-GB/facturen/corrigeren)

You cannot simply change a booked invoice. Which route you choose depends on how far the invoice has progressed.

All corrections except reverting are in the actions menu (three dots) next to **Send notification**.

<DocScreenshot src="/screenshots/facturen/invoice-correct-menu.png" alt="Actions menu of a booked invoice with Copy invoice and Reverse invoice" />

| Situation | What you do |
|----------|-------------|
| The invoice has just been booked and not yet sent | [Revert to draft](#terugzetten-naar-concept) |
| The invoice has already been sent or is too old | [Reverse](#een-factuur-omkeren) with a credit invoice |
| You want to reuse the same lines | [Copy](#een-factuur-kopiëren) |
| The invoice is on the wrong customer | [Move](#een-factuur-verplaatsen-naar-een-andere-klant) |
| The amounts are wrong | [Recalculate](#een-factuur-herberekenen) |

## Reverting to draft [#terugzetten-naar-concept]

As long as the invoice has not left the building, you revert it to draft and book it again after your change.

It is possible if all of the following apply:

- The invoice is booked.
- Tillor has not yet sent a notification for it, through any channel.
- The invoice has not been sent via Peppol.
- The invoice date is less than 7 days ago.

<Steps>
<Step>
### Open the booked invoice [#open-de-geboekte-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open the invoice.
</Step>
<Step>
### Revert it [#zet-hem-terug]
Click **Revert to draft** and confirm with **Yes, revert to draft**. If the button is not there, the invoice does not meet the conditions.
</Step>
<Step>
### Change the invoice and book again [#pas-de-factuur-aan-en-boek-opnieuw]
Change the lines and click **Book invoice**.
</Step>
</Steps>

In the meantime the invoice has a draft number with the original number in brackets. The **Rounding** line is removed and comes back when you book again. When you book again, the invoice gets its original number back, with the original invoice date and due date. A draft that comes from a booked invoice cannot be deleted.

After a revert, that event on the **Events** timeline has a **Restore version** button. With it you replace the current lines with the lines as they were at the moment of reverting. If the invoice has been booked again by then, Tillor first reverts it to draft again.

<Callout type="warn" title="Be careful">
If the invoice has already been printed, shown to the customer or shared in some other way, be careful. The customer then has a version that will soon no longer be correct.
</Callout>

### When reverting is no longer possible [#als-terugzetten-niet-meer-kan]

<Requires permission="Invoice corrections" />

If the invoice no longer meets the conditions, for example because a notification has already been sent or the invoice is older than 7 days, you can still revert it with the **Invoice corrections** permission. Open the three dots at the top right of the invoice page and choose **Force revert to draft**. Only use this if it is legally and accounting-wise acceptable. A credit invoice via [reversing](#een-factuur-omkeren) is usually the cleaner solution.

## Reversing an invoice [#een-factuur-omkeren]

By reversing you create a credit invoice that cancels a booked invoice. This always works, even if the invoice has already been sent or paid.

<Steps>
<Step>
### Reverse the invoice [#keer-de-factuur-om]
Open the three dots at the top right of the booked invoice and choose **Reverse invoice**. Tillor creates a new draft with the same lines in negative amounts and opens it.
</Step>
<Step>
### Check and book [#controleer-en-boek]
Adjust the draft if needed and click **Book invoice**. It then becomes a **Credit Invoice**.
</Step>
</Steps>

The two invoices refer to each other. In the **Invoice Information**, the credit invoice shows **Reversal of** and the original invoice shows **Reversed as**. In the invoice list on the customer profile you see the label **Reversal draft** on the draft and **This invoice was reversed** on the original invoice.

If you have reversed an invoice before, Tillor asks for confirmation with **Yes, reverse again**, so you do not accidentally create two credit invoices.

If you want to offset the credit invoice against the original invoice, choose **Internal Transfer** when paying. See [Internal transfer](/betalingsverwerking/interne-overboeking).

## Copying an invoice [#een-factuur-kopiëren]

Choose **Copy invoice** in the actions menu of a booked invoice. Tillor creates a new draft with the same lines, the same note and the same direct-debit mandate, and opens it. The **Rounding** line is not copied.

## Moving an invoice to another customer [#een-factuur-verplaatsen-naar-een-andere-klant]

<Requires permission="Invoice corrections" />

If an invoice is on the wrong customer, you move it.

<Steps>
<Step>
### Open the actions menu [#open-het-actiemenu]
Click the three dots at the top right of the invoice page and choose **Move to customer**.
</Step>
<Step>
### Choose the customer [#kies-de-klant]
Choose the **Target customer** and click **Move invoice**.
</Step>
</Steps>

The invoice moves along with the linked payments, meter batches and comments. A booked invoice is then sent to your accounting again. If the invoice has already been sent via Peppol, you cannot move it.

## Recalculating an invoice [#een-factuur-herberekenen]

If the amounts on a booked invoice do not match the lines, choose **Recalculate invoice** in the actions menu. Tillor recalculates the totals.

## Deleting a draft [#een-concept-verwijderen]

You can delete a draft invoice with **Delete invoice** in the actions menu. You then return to the customer's profile. You cannot delete booked invoices, you reverse those.

## What happens next? [#wat-gebeurt-er-daarna]

| Route | Result |
|-------|--------|
| Revert to draft | The invoice number is kept. When you book again, the invoice gets its original number and dates back. |
| Reverse | A credit invoice is created that refers to the original invoice. You can offset it with an [internal transfer](/betalingsverwerking/interne-overboeking). |
| Copy | A new draft is created. The original invoice does not change. |
| Move | Payments, meter batches and comments move along. A booked invoice goes to your accounting again. |
| Recalculate | The totals are recalculated from the lines. |

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Revert to draft">
One of the conditions is not met. Has a notification already been sent or is the invoice 7 days or older? Then you can reverse it, or with the **Invoice corrections** permission force a revert.
</Accordion>
<Accordion title="Move to customer is missing">
You need the **Invoice corrections** permission for that. If the invoice has been sent via Peppol, moving is not possible.
</Accordion>
<Accordion title="Which permissions does my user have?">
An administrator sets those. See [Users](/gebruikers).
</Accordion>
</Accordions>

## Next [#verder]

<Cards>
  <Card title="Booking an invoice" href="/facturen/boeken" />
  <Card title="Statuses" href="/facturen/statussen" />
  <Card title="Peppol" href="/boekhouden/peppol" description="Sending invoices via Peppol" />
</Cards>


# Overview (/en-GB/facturen)

Under <UIPath>Administration > Invoices</UIPath> you find all invoices of your park, with the outstanding amounts at the top. An invoice starts as a draft and only becomes final when you book it. After that you can send it, have it paid and correct it if needed.

<Callout type="info" title="Good to know">
- You create a new invoice on the customer profile, not from this list.
- A booked invoice gets a due date: the day of booking plus your organisation's default due date, 7 days by default. You can choose a different term per invoice.
- If the total is not a multiple of 5 cents, Tillor adds a **Rounding** line when booking.
- Tillor does not send a booked invoice to the customer by itself. You do that yourself with **Send notification**.
- You can revert to draft up to 7 days after the invoice date, as long as no notification has been sent and the invoice has not been sent via Peppol. After that you reverse the invoice with a credit invoice.
- A cash payment may be at most 2999 euros by default. You change that with **Cash payment maximum** under <UIPath>Support > Settings > Payments</UIPath>.
- A direct debit with a SEPA mandate goes to the bank two days after booking. Until then you can cancel the payment.
- The personal link of an invoice has no expiry date. The customer sees what is still outstanding there.
- If the customer has a Peppol ID, Tillor automatically sends the invoice via Peppol after booking.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

An invoice is the start of a chain. A payment belongs to a booked invoice, the payments of a day go into a payment report and that report goes to your accounting.

```mermaid
flowchart LR
  A[Draft invoice] -- Book --> B[Booked invoice]
  B -- Send notification --> K[Customer receives the invoice]
  K -- Customer pays online --> C[Payment]
  B -- You register a payment --> C
  C -- Balance and payment status --> B
  C -- Bundled per day --> D[Payment report]
  D -- Mollie and internal transfers --> E[Accounting]
```

- The outstanding balance and the payment status of the invoice follow automatically from the payments.
- A payment without an invoice can be linked to a booked invoice later.
- Which payments go to the accounting is described under [Accounting](/boekhouden).

## The invoice list [#de-facturenlijst]

At the top are four counters: **Total Invoices**, **Open Invoices** (unpaid or partially paid), **Overdue Invoices** (due date passed) and **Total Outstanding** (the total amount of the open invoices).

Below that are four lists:

- **Pending Payments**: booked invoices whose payment has started but has not definitively come in yet
- **Invoices with Open Balance**: booked invoices with an amount that still has to be paid, sorted by due date
- **Drafts**: the ten most recently created draft invoices
- **All Invoices**: the full list, filtered on booked invoices by default

<DocScreenshot src="/screenshots/facturen/invoices-list.png" alt="Invoice overview - All invoices" />

You do not create new invoices from this list. You do that on the customer profile, see [Creating an invoice](/facturen/aanmaken-en-bewerken#een-factuur-aanmaken).

### Searching and filtering [#zoeken-en-filteren]

The search bar searches on invoice number, the customer's first or last name, email address and amount. In the **All Invoices** list you can also filter on:

| Filter | What you do with it |
|--------|-------------------|
| **Period** | Only invoices within a certain period |
| **Status** | **Draft** or **Booked** |
| **Payment Status** | **Unpaid**, **Partially**, **Pending** or **Paid** |
| **Customer Type** | **Standard**, **Worker Rental Caravan** or **Worker Towing Caravan** |
| **Customer** | All invoices of one customer |
| **Products** | Invoices with a certain product on a line |
| **Amount** | Invoices with a minimum or maximum amount |

In the **Invoices with Open Balance** list there is also the **Due for a reminder** filter. You choose a number of days (7 to 90) and then see the overdue invoices that were created at least that long ago and for which no reminder by email or SMS has been sent in recent days. Handy for deciding whom to remind again.

<DocScreenshot src="/screenshots/facturen/invoice-open-balance.png" alt="Invoices with open balance" />

### Invoices per customer [#facturen-per-klant]

On a customer profile you find all invoices of that customer in the **Invoices** block on the **Overview** tab, or on the **Invoicing** tab. You also create a new invoice there.

## Guides [#handleidingen]

<Cards>
  <Card title="Creating and editing" href="/facturen/aanmaken-en-bewerken" description="Create a draft invoice and add lines" />
  <Card title="Booking an invoice" href="/facturen/boeken" description="Make the invoice final" />
  <Card title="Sending an invoice" href="/facturen/versturen" description="Notification or reminder to the customer" />
  <Card title="Registering payments" href="/facturen/betalingen-registreren" description="Record or link a payment" />
  <Card title="Printing and downloading" href="/facturen/afdrukken-en-downloaden" description="PDF, printer and personal link" />
  <Card title="Correcting" href="/facturen/corrigeren" description="Reverting, reversing, copying and moving" />
  <Card title="Statuses" href="/facturen/statussen" description="What Draft, Booked and Paid mean" />
</Cards>

## Related [#gerelateerd]

<Cards>
  <Card title="Payment processing" href="/betalingsverwerking" description="Payment methods in detail" />
  <Card title="Products" href="/producten" description="Actions on invoice lines" />
  <Card title="Accounting" href="/boekhouden" description="Payment reports and accounting integrations" />
  <Card title="Practical examples" href="/praktijk" description="Worked examples from practice" />
</Cards>

## Terms [#begrippen]

- **Draft**: an invoice you can still change, with a temporary draft number.
- **Booked**: a final invoice with its own invoice number. See [Booking](/begrippen#boeken).
- **Credit Invoice**: a booked invoice with a negative total, for example after reversing an invoice.
- **Payment status**: whether and how much of the invoice has been paid. See [Statuses](/facturen/statussen).
- **Customer**: the customer the invoice is for. See [Customer](/begrippen#klant).
- **Occupation**: a customer on a terrain for a period. See [Occupation](/begrippen#bezetting).


# Invoice statuses (/en-GB/facturen/statussen)

Every invoice has a **status** (whether it is final yet) and, once it is booked, a **payment status** (how much has been paid). You can filter on both in the [invoice list](/facturen).

<DocScreenshot src="/screenshots/facturen/invoices-list.png" alt="Invoice list with status and payment status per invoice" />

## Invoice status [#factuurstatus]

| Status | Meaning |
|--------|-----------|
| <Status>Draft</Status> | The invoice can still be edited and has a temporary draft number. You cannot send it or have it paid yet. |
| <Status tone="success">Booked</Status> | The invoice is final and has its own invoice number. You can send it, have it paid and correct it. |

A draft that has been reverted from a booked invoice has a draft number with the original invoice number in brackets. See [Correcting an invoice](/facturen/corrigeren).

## Payment status [#betalingsstatus]

The payment status is shown next to the invoice number of a booked invoice.

| Status | Meaning |
|--------|-----------|
| <Status tone="error">Unpaid</Status> | Nothing has been paid yet. |
| <Status tone="warning">Partially</Status> | Part has been paid and an amount is still outstanding. |
| <Status tone="info">Pending</Status> | The full amount has been initiated, for example a direct debit, but the money has not been definitively processed yet. |
| <Status tone="success">Paid</Status> | The invoice has been fully settled. |

An invoice is **overdue** if the due date has passed and an amount is still outstanding. That is not a separate status. You see it in the **Overdue Invoices** counter on the invoice list.

## Invoice type [#factuurtype]

| Type | Meaning |
|------|-----------|
| **Invoice** | A normal invoice with a positive total. |
| **Credit Invoice** | A booked invoice with a negative total, for example after [reversing an invoice](/facturen/corrigeren#een-factuur-omkeren). |

## Labels in the list on the customer profile [#labels-in-de-lijst-op-het-klantprofiel]

| Label | Meaning |
|-------|-----------|
| **Sent via Peppol** | The invoice has been sent via Peppol. |
| **Reversal draft** | This draft was created to reverse another invoice. |
| **This invoice was reversed** | A credit invoice or draft exists that cancels this invoice. |

## Next [#verder]

<Cards>
  <Card title="Overview" href="/facturen" description="The invoice list and filters" />
  <Card title="Registering payments" href="/facturen/betalingen-registreren" />
</Cards>


# Sending an invoice (/en-GB/facturen/versturen)

With **Send notification** you send the customer a booked invoice by email, SMS, WhatsApp or post. Tillor never does that by itself. If the invoice has already been sent but not yet paid, you send a reminder. The customer can then pay via the link in the message, see [Letting a customer pay online](/betalingsverwerking/online).

Before you start:

- The invoice is booked. On a draft the buttons are missing.
- The customer has at least an email address, a phone number or a complete postal address (street, postcode and town). Otherwise the buttons are missing.
- For a reminder, an amount is still outstanding.

## Sending an invoice [#een-factuur-versturen]

<Steps>
<Step>
### Open the booked invoice [#open-de-geboekte-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open an invoice with status <Status tone="success">Booked</Status>.
</Step>
<Step>
### Click Send notification [#klik-op-verstuur-notificatie]
A **Send notification** window opens.
</Step>
<Step>
### Choose the channels [#kies-de-kanalen]
You can choose from:

- **Email**: the customer receives an email with the invoice attached. On by default if there is an email address.
- **SMS**: the customer receives a text message. Only available with a phone number.
- **WhatsApp**: only visible if WhatsApp Business is installed. Requires a phone number, and a payment method at Meta or an ongoing conversation with the customer.
- **Post**: the invoice is sent as a PDF by post. Only available with a complete postal address. Off by default and shows an indicative postage amount per letter.

A channel that is not possible for this customer is disabled with the reason, for example **No email address on file**. Choose at least one channel.
</Step>
<Step>
### Send [#verstuur]
Click **Send**.
</Step>
</Steps>

## Sending a reminder [#een-aanmaning-versturen]

A reminder is possible as soon as the invoice is booked and an amount is still outstanding.

<Steps>
<Step>
### Open the dropdown menu [#open-het-keuzemenu]
Click the arrow next to **Send notification** and choose **Send reminder**.
</Step>
<Step>
### Choose the channels [#kies-de-kanalen-1]
Here **Email** and **SMS** are on by default if the customer has an email address and phone number. With **Post**, the customer receives a reminder letter with the invoice attached, with a QR code to view or pay online.

<DocScreenshot src="/screenshots/facturen/invoice-reminder-dialog.png" alt="Confirmation dialog for sending a reminder" />
</Step>
<Step>
### Optionally choose registered mail [#kies-eventueel-aangetekend]
If you ticked **Post**, you can choose **Registered mail with receipt confirmation**. That is only possible for a reminder, not for the first invoice notification, and only if registered mail is available for that address. Tillor then shows the indicative extra amount on top of the normal postage costs. The button is then called **Send with extra cost**.
</Step>
<Step>
### Send [#verstuur-1]
Click **Send**.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

On the invoice page, the **Notifications** block shows which messages have been sent. All messages of your organisation are under <UIPath>Communication > Notifications</UIPath>.

Postal items start as **Pending**. The status of the letter then follows: **PDF received**, **Validated**, **Processing**, **In print center** and **Handed to postal service**. As soon as the carrier confirms it, the status becomes **Sent**. Undeliverable post becomes **Failed**. A letter that has been cancelled at the carrier gets the status **Skipped**. Open the message for the postage amount, the carrier's reference and the latest tracking status. More about this is under [Notifications](/notificaties).

- Tillor sends the message immediately. The customer receives a link to view the invoice and pay online.
- A reminder remains a separate action per invoice. The **Due for a reminder** filter in the [invoice list](/facturen) helps you choose whom to remind again.
- Automations can also send reminders automatically. See [Automations](/automatiseringen).

<Callout type="info">
An invoice for which a notification has already been sent can no longer easily be reverted to draft. See [Correcting an invoice](/facturen/corrigeren#terugzetten-naar-concept).
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Send notification">
The invoice must be booked, and the customer must have an email address, a phone number or a complete postal address. Complete the details on the customer profile.
</Accordion>
<Accordion title="I do not see Send reminder">
A reminder is only possible for a booked invoice with an outstanding amount.
</Accordion>
<Accordion title="The message failed">
Open the message under <UIPath>Communication > Notifications</UIPath> for the error message. Then check the customer's email address, phone number or postal address and send again. See [Notifications](/notificaties).
</Accordion>
</Accordions>

## Next [#verder]

<Cards>
  <Card title="Notifications" href="/notificaties" description="Status and history of sent messages" />
  <Card title="Registering payments" href="/facturen/betalingen-registreren" />
</Cards>


# Invite users and give permissions (/en-GB/gebruikers/gebruikers-en-rechten)

A colleague with a Tillor account is called a user in Tillor. You decide who has access to your organisation and what that person may see and do, using permissions. For colleagues you often address together, you can then create a [group](/gebruikers/groepen).

Before you start:

- You need the **Manage user permissions** permission. Without it, the **Invite user** and **Edit permissions** buttons are greyed out.
- You can only give permissions you have yourself. A permission you lack cannot be switched on for someone else.
- Only a user with **All permissions** can give the **Manage user permissions** permission itself to someone else.

## Invite a colleague [#een-collega-uitnodigen]

<Steps>
<Step>
### Open the users [#open-de-gebruikers]
Go to <UIPath>Support > Settings > Users</UIPath>. You see the **Members** of your organisation and the **Pending invitations**.

<DocScreenshot src="/screenshots/gebruikers/settings-membership-permissions.png" alt="Settings > Users with the list of members" />
</Step>
<Step>
### Click Invite user [#klik-op-gebruiker-uitnodigen]
The **Invite user** window opens.

<DocScreenshot src="/screenshots/gebruikers/settings-members-invite-dialog.png" alt="The Invite user window" />
</Step>
<Step>
### Enter the email address [#vul-het-e-mailadres-in]
Type your colleague's **Email address** and click **Invite**.
</Step>
</Steps>

What happens next depends on the email address:

<Tabs items={["There is already a Tillor account", "No Tillor account yet"]}>
<Tab value="There is already a Tillor account">
The user immediately becomes a member of your organisation. Tillor says **User added to the organization**. The person sees your organisation straight away among their organisations.
</Tab>
<Tab value="No Tillor account yet">
Tillor says **Invitation sent** and sends an invitation by email. Until the person signs in for the first time, they appear under **Pending invitations** with the **Pending** badge. On first sign-in they become a member of your organisation. With **Revoke invitation** you withdraw the invitation, and Tillor says **Invitation revoked**.
</Tab>
</Tabs>

A new user starts with these permissions: **View settings**, **Edit settings**, **View integrations**, **Manage integrations**, **Meter alarm notifications**, **Inbox message notifications**, **Tablet and kiosk alerts**, **Manage signature requests** and **Manage custom fields**. Check whether that suits the person and adjust it.

## Edit permissions [#rechten-bewerken]

<Steps>
<Step>
### Click Edit permissions on the user [#klik-bij-de-gebruiker-op-rechten-bewerken]
The **Edit user permissions** window opens. At the top are the groups the user is a member of. With **Search permissions** you find a permission quickly.

<DocScreenshot src="/screenshots/gebruikers/settings-membership-permissions-dialog.png" alt="The Edit user permissions window with permissions per area" />
</Step>
<Step>
### Switch permissions on or off [#zet-rechten-aan-of-uit]
Permissions are grouped per area, such as **Invoicing**, **Payments** or **Inbox**. At the bottom you see how many effective permissions the user has.
</Step>
<Step>
### Save the permissions [#sla-de-rechten-op]
Click **Save permissions**. Tillor says **User permissions saved**.
</Step>
</Steps>

### Where does a permission come from? [#waar-komt-een-recht-vandaan]

Each permission shows its source. That way you can see why someone can or cannot do something.

| Source | Meaning |
|---|---|
| **Direct** | You gave the permission directly to this user. You can switch it off here |
| A group name | That [group](/gebruikers/groepen#groepsrechten) gives the permission. You cannot switch it off here, only on the group |
| **Blocked** with a group name | That group denies the permission. Even if the user had it themselves, it stays blocked |
| **Not granted** | Nobody gives the permission |

The **Edit permissions** button is greyed out for your own row and for users with the **All permissions** badge. Those users have everything and you cannot restrict them.

## Set a colleague's notifications [#meldingen-van-een-collega-instellen]

With the bell icon (**Notification settings**) on a user you open their notifications in this organisation. For each notification you choose email, push or phone call. With **All notifications** you switch off a channel in one go. Changes take effect immediately and only apply in this organisation.

<DocScreenshot src="/screenshots/gebruikers/settings-members-notifications-dialog.png" alt="The window with a colleague's notifications" />

Notifications that are always sent cannot be switched off. What a notification is and where you see them is described under [Notifications](/notificaties#meldingen-in-de-app).

## Remove a user [#een-gebruiker-verwijderen]

Click the bin icon (**Remove from organization**) and confirm with **Remove user**. Tillor says **User removed from the organization**. The person immediately loses access to this organisation. Their Tillor account remains, and so do any other organisations.

You cannot remove yourself. You can only remove a user with **All permissions** if you also have **All permissions** yourself.

## What happens next? [#wat-gebeurt-er-daarna]

- The user sees your organisation among their organisations and can use whatever they have permissions for.
- A change in permissions applies immediately after saving.
- A removed user loses access immediately. Their Tillor account remains.

## Problems? [#problemen]

<Accordions>
<Accordion title="The Invite user button is greyed out">
You do not have the **Manage user permissions** permission. Ask a colleague with **All permissions** to give it to you.
</Accordion>
<Accordion title="Tillor says Failed to invite user">
That email address is already a member of your organisation, or an invitation for that address is already pending. Check the **Members** and **Pending invitations** lists. If the invitation is already there, revoke it and invite again if the person did not receive the email.
</Accordion>
<Accordion title="The invited person cannot find their email">
Ask them to check their spam. They only become a member when they sign in with exactly the email address you invited. If they sign in with a different address, revoke the invitation and invite that address.
</Accordion>
<Accordion title="A permission is greyed out and I cannot switch it on">
You can only give permissions you have yourself. If a group name is shown next to the permission, that group gives or blocks the permission and you change it on the group.
</Accordion>
<Accordion title="Edit permissions is greyed out for a colleague">
The colleague has **All permissions**, or it is your own row. You cannot edit those.
</Accordion>
<Accordion title="A colleague is missing a button although I gave them the permission">
In the **Edit user permissions** window, check whether a group shows the permission as **Blocked**. A denial from a group always wins over a permission you gave directly.
</Accordion>
<Accordion title="I cannot remove a user">
You cannot remove yourself. You can only remove a user with **All permissions** if you also have **All permissions** yourself.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Groups" href="/gebruikers/groepen" description="Bundle colleagues and set permissions per group" />
  <Card title="Notifications" href="/notificaties" description="How notifications arrive" />
  <Card title="Visibility and access of custom fields" href="/eigen-velden/zichtbaarheid-en-toegang" description="Permissions per custom field" />
  <Card title="Organisation" href="/gebruikers/organisaties" description="All parts of Settings" />
</Cards>


# Groups (/en-GB/gebruikers/groepen)

A group is a fixed set of colleagues, for example **Reception** or **Technical team**. You use a group in these places:

- **Assigning tasks**: search for the group name when you assign a task
- **Mentioning and notifying**: a mention or notification to a group goes to all its members
- **Sharing views**: for a task view, choose **Specific groups**, see [Views](/taken/weergaven#wie-ziet-een-weergave)
- **Automations**: the steps that create or update a task can assign to groups

## Create a group [#een-groep-maken]

<Steps>
<Step>
### Open Groups [#open-groepen]
Go to <UIPath>Support > Settings > Groups</UIPath>.

<DocScreenshot src="/screenshots/gebruikers/settings-groups.png" alt="Settings > Groups with two groups" />
</Step>
<Step>
### Click New group [#klik-op-nieuwe-groep]
Enter a **Name**, for example Reception.
</Step>
<Step>
### Choose the members [#kies-de-leden]
Under **Members**, choose the people. You can only add users who are already members of the organisation.
</Step>
<Step>
### Click Save [#klik-op-opslaan]
Tillor says **Group saved**.
</Step>
</Steps>

Click a group to change its name or members. If you delete a group, tasks stay assigned to the people who are assigned to them directly. Only the group itself disappears.

## Group permissions [#groepsrechten]

A group can also give or take away permissions. On the group, click the key icon (**Group permissions**). For each permission you choose:

| Choice | What it does |
|---|---|
| **Allow** | Everyone in the group gets the permission ("Granted to all") |
| **Inherit** | The group does nothing with this permission. Each member keeps their own access ("Inherits own access"). This is the initial setting |
| **Deny** | The permission is blocked for everyone in the group ("Blocked for all") |

<DocScreenshot src="/screenshots/gebruikers/settings-group-permissions-dialog.png" alt="The Group permissions window with Deny, Inherit and Allow" />

With **Search permissions** you find a permission quickly. At the bottom you see how many permissions you have set. Click **Save**, after which Tillor says **Group permissions saved**.

<Requires permission="Manage user permissions" />

Without that permission, the **Group permissions** button is greyed out. You also cannot delete a group that still has group permissions.

## What happens next? [#wat-gebeurt-er-daarna]

- Group permissions come on top of each member's own permissions. A denial always wins: if a permission is set to **Deny** on one group and **Allow** on another, it stays blocked.
- In a member's **Edit user permissions** window you see for each permission which group gives or blocks it. See [Edit permissions](/gebruikers/gebruikers-en-rechten#rechten-bewerken).
- If you add a member, the group permissions apply to that member too. If you remove them, they no longer do.
- Assigning a task, mentioning someone or sending a notification to the group reaches everyone who is a member at that moment.

## Groups from Microsoft Entra [#groepen-uit-microsoft-entra]

If you already manage your staff in Microsoft Entra ID, Entra can keep a group's members up to date automatically. Below the list of groups you then see the **Entra groups** table, where you link each Entra group to a Tillor group.

<Callout type="info">
For a linked group, Entra is the source. A member you add or remove by hand in Tillor is set back in line with Entra at the next synchronisation.
</Callout>

See [Microsoft Entra groups](/gebruikers/microsoft-entra) to set up the link.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says The group could not be saved">
Try again. If it keeps failing, contact Tillor support.
</Accordion>
<Accordion title="The Group permissions button is greyed out">
You do not have the **Manage user permissions** permission.
</Accordion>
<Accordion title="A member cannot do something although the group allows it">
Another group of that member denies that permission. A denial always wins. Open the member's **Edit user permissions** window to see which group blocks it.
</Accordion>
<Accordion title="I do not see a member in the selection list">
Only users of your organisation are in the list. Invite the person first. See [Invite users](/gebruikers/gebruikers-en-rechten).
</Accordion>
<Accordion title="A member keeps disappearing from the group">
If the group is linked to Microsoft Entra, Entra is the source and the next synchronisation sets the members back in line. Change the member in Entra.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Microsoft Entra groups" href="/gebruikers/microsoft-entra" description="Keep groups up to date automatically from Entra" />
  <Card title="Views" href="/taken/weergaven" description="Share a task view with a group" />
  <Card title="Organisation" href="/gebruikers/organisaties" description="Settings and user permissions" />
</Cards>


# Overview (/en-GB/gebruikers)

This is where you arrange who works with Tillor and what they may do: invite users, give permissions, put colleagues in groups and adjust your organisation's settings. A user is anyone with an account who has access to your organisation. You manage this under <UIPath>Support > Settings</UIPath>.

<DocScreenshot src="/screenshots/gebruikers/settings-membership-permissions.png" alt="Settings > Users with the list of members" />

<Callout type="info" title="Good to know">
- A new user gets a fixed set of starting permissions (settings, integrations, a few notifications, signature requests and custom fields). You give everything else
- You can only give permissions you have yourself. Only a user with **All permissions** can pass on the **Manage user permissions** permission
- A denial via a group always wins over a permission you gave directly
- You cannot remove yourself or edit your own permissions
- You have no separate Tillor password: you sign in with Google, Microsoft or Apple
- You do not change company details such as the VAT number or IBAN yourself. Tillor support does that
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

A user has permissions in two ways: directly, or through a group. A group can also deny a permission.

```mermaid
flowchart TD
  U[User] -->|given directly| R[The user's permissions]
  U -->|is a member of| G[Group]
  G -->|Allow| R
  G -->|Inherit| N[Does nothing, the user keeps their own permissions]
  G -->|Deny| B[Permission blocked, even if the user had it themselves]
  R --> A[What the user sees and may do in Tillor]
  B --> A
```

- **Direct**: you switch a permission on in the **Edit user permissions** window. See [Invite users and give permissions](/gebruikers/gebruikers-en-rechten).
- **Through a group**: under **Group permissions** you choose **Allow**, **Inherit** or **Deny** for each permission. That applies to everyone in the group. See [Groups](/gebruikers/groepen).
- **Denied**: if a permission is set to **Deny** on one group, it is blocked, however many other groups or direct permissions give it.
- You use the same groups for assigning tasks, mentioning and sharing views.

## Your own account [#je-eigen-account]

In the sidebar, click your name (at the bottom) and choose **Account**. There you manage your profile, phone number, active sessions, OAuth apps and linked sign-in platforms. Under **Notifications** you choose, for each notification, whether Tillor reaches you by email or push. See [Sign-in & access](/inloggen).

## API keys [#api-sleutels]

An API key lets another program talk to Tillor on your behalf. It belongs to your account. You manage them on your account page.

<Steps>
<Step>
### Open your account [#open-je-account]
In the sidebar, click your name (at the bottom) and choose **Account**.
</Step>
<Step>
### Create the key [#maak-de-sleutel]
Open the **API Keys** section and click **Create API Key**.
</Step>
<Step>
### Copy it straight away [#kopieer-hem-meteen]
After that, Tillor no longer shows the full key.
</Step>
</Steps>

Via **Developers** (same user menu) you also find the shortcut **Go to API Keys**.

<Callout type="warn">
Keep API keys safe and never share them through insecure channels. If a key has leaked, delete it or click **Regenerate** and create a new one if needed.
</Callout>

## Parts [#onderdelen]

<Cards>
  <Card title="Invite users and give permissions" href="/gebruikers/gebruikers-en-rechten" description="Add colleagues and decide what they may do" />
  <Card title="Groups" href="/gebruikers/groepen" description="Assign, mention and give permissions to colleagues together" />
  <Card title="Microsoft Entra groups" href="/gebruikers/microsoft-entra" description="Keep group members up to date automatically from Entra" />
  <Card title="Organisation" href="/gebruikers/organisaties" description="All parts of Settings" />
  <Card title="Invoicing settings" href="/gebruikers/instellingen-facturatie" description="PDF, payment term and VAT rates" />
  <Card title="Payment settings" href="/gebruikers/instellingen-betalingen" description="Other, reminders and sender address" />
  <Card title="Set up rental periods" href="/gebruikers/instellingen-huurperiodes" description="Rental frequencies for occupancies" />
  <Card title="Access control settings" href="/gebruikers/instellingen-toegangscontrole" description="Leaving with an expired number plate" />
  <Card title="Developers" href="/ontwikkelaars" description="Integration documentation and webhooks" />
</Cards>

## Terms [#begrippen]

- **User**: someone with an account who has access to your [organisation](/begrippen#organisatie).
- **[Permission](/begrippen#recht)**: authorisation to see or do something, such as **Edit products**.
- **All permissions**: a badge for users who may do everything. You do not edit their permissions.
- **[Group](/begrippen#groep)**: a fixed set of colleagues, optionally with permissions of their own.
- **Invitation**: a pending request to someone without an account to become a member.
- **API key**: a code that lets another program work with Tillor.

More terms are in the [glossary](/begrippen).


# Payment settings (/en-GB/gebruikers/instellingen-betalingen)

Under <UIPath>Support > Settings > Payments</UIPath> are a few settings that affect how payments are recorded and how notifications are sent. The settings apply to your whole organisation.

<Requires permission="Instellingen bewerken" />

<DocScreenshot src="/screenshots/instellingen/settings-payments.png" alt="Settings > Payments" />

## Settings [#instellingen]

| Setting | What it does |
|---|---|
| **Show "Others" payment method** | Puts the **Others** method in the payment screen. With it you record payments with a description of your own, for example a cheque or a swap. Off by default. |
| **Default: manual bank transfer reminder** | Switches the tick for the reminder about the structured reference on by default when you record a manual bank transfer. You can still switch the tick on or off per payment. Off by default. |
| **Cash payment maximum** | An amount in whole euros. 2999 by default. |
| **Email sender address** | The address Tillor uses to send notifications by email. |

## Cash payment maximum [#maximumbedrag-contant]

With **Cash payment maximum** you decide how high a single cash payment may be. By default that is 2999 euros. Tillor checks it on every cash payment, including one that arrives through an integration. If the amount is higher, record it in parts or choose another method. See [Cash and bank transfer](/betalingsverwerking/contant).

## Sender address of notifications [#afzenderadres-van-meldingen]

If you leave **Email sender address** empty, your organisation's name is shown as the sender of notifications, with a Tillor address. If you enter a valid email address, for example `meldingen@recreatiepark-het-meer.be`, Tillor uses that address, with your organisation's name as the sender name. Enter only the address, without a name. An invalid address is not saved.

## Save changes [#wijzigingen-opslaan]

At the bottom, click **Save settings**. With **Cancel** you reset the form to the saved values.

## See also [#zie-ook]

<Cards>
  <Card title="Cash and bank transfer" href="/betalingsverwerking/contant" description="Record payments that arrived outside Tillor" />
  <Card title="Record payments on an invoice" href="/facturen/betalingen-registreren" description="Payment methods and fields in the payment screen" />
  <Card title="Invoicing settings" href="/gebruikers/instellingen-facturatie" description="Payment term, VAT and PDF" />
</Cards>


# Invoicing settings (/en-GB/gebruikers/instellingen-facturatie)

Under <UIPath>Support > Settings > Invoicing</UIPath> you set the defaults for invoices and for the PDF you send to customers. The settings apply to your whole organisation.

<Requires permission="Instellingen bewerken" />

<DocScreenshot src="/screenshots/instellingen/settings-invoicing.png" alt="Settings > Invoicing" />

## What appears on the invoice PDF [#wat-staat-er-op-de-factuur-pdf]

| Setting | What it does |
|---|---|
| **General terms on invoice PDF** | The PDF gets a back page with general terms for every page. The footer refers to it. The text of the terms is fixed and names your organisation's legal name. Off by default. |
| **VAT breakdown table on invoice PDF** | Next to the totals is a table with the taxable amount and the VAT amount per VAT rate. Off by default. |
| **Invoice PDF items per page** | The maximum number of lines on a page. If there are more lines, a new page follows. 20 by default, minimum 1. |

## Payment term [#betaaltermijn]

Under **Default due date (days)** you enter the number of days between the invoice date and the due date. It applies to invoices for which you did not choose a due date yourself. By default that is 7 days. You can enter 0, in which case the invoice is due on the day of booking. See [Book an invoice](/facturen/boeken).

## Choose VAT rates [#btw-tarieven-kiezen]

Under **Allowed VAT rates** are the rates you can choose in the VAT dropdown on draft invoices. By default these are 0%, 6%, 9%, 12% and 21%.

1. Type a percentage between 0 and 100 in the field below the list. A comma or a full stop is allowed.
2. Click **Add rate**.
3. Remove a rate with the cross next to the percentage.
4. Click **Save settings**.

The list is always sorted from low to high. You cannot add a rate that is already in the list twice. If an existing invoice line has a rate that you later remove from the list, that rate stays on that line.

You only see that dropdown if **VAT rate dropdown on draft invoice lines** is on. A draft invoice then gets a VAT column in which you choose a rate per line. If you choose a product, that product's rate remains the initial value. See [VAT](/boekhouden/belasting) and [Create and edit invoices](/facturen/aanmaken-en-bewerken).

## Automatic invoices for consumption [#automatische-facturen-voor-verbruik]

Under **Minimum amount for automatic utility invoices** you enter an amount in euros. For customers with automatic invoicing of utilities, Tillor only creates an invoice once the outstanding amount reaches this amount. If you leave the field empty (**No minimum**), every outstanding amount is invoiced.

If a customer has a minimum of their own on the customer profile, that minimum applies to that customer instead of this setting. See [Meter management](/meterbeheer).

## Save changes [#wijzigingen-opslaan]

At the bottom, click **Save settings**. With **Cancel** you reset the form to the saved values. If you only have the **View settings** permission, the fields are greyed out.

## See also [#zie-ook]

<Cards>
  <Card title="Book an invoice" href="/facturen/boeken" description="Invoice date and due date" />
  <Card title="VAT" href="/boekhouden/belasting" description="VAT rates and VAT on invoices" />
  <Card title="Payment settings" href="/gebruikers/instellingen-betalingen" description="Cash, Others and sender address" />
</Cards>


# Set up rental periods (/en-GB/gebruikers/instellingen-huurperiodes)

For an occupancy you choose a **Rent frequency**. Which choices you see there is decided under <UIPath>Support > Settings > Occupation</UIPath>. Every period you add here becomes a choice in the list.

<Requires permission="Instellingen bewerken" />

<DocScreenshot src="/screenshots/instellingen/settings-occupation.png" alt="Settings > Occupation with a new period" />

## Add a period [#een-periode-toevoegen]

<Steps>
<Step>
### Add a period [#voeg-een-periode-toe]
Open **Occupation** and click **Add period**. A block appears with the initial values: January, 12 months.
</Step>
<Step>
### Fill in the period [#vul-de-periode-in]
Choose the **Start month** and enter a number from 1 to 12 under **Duration (months)**. A period of 12 months that starts in January is a calendar year. A period of 1 month is a monthly rent. Under **Label** you can enter a name of your own, for example Yearly.
</Step>
<Step>
### Choose how to round [#kies-hoe-je-afrondt]
The tick **Round start dates to the next period** is on by default. What it does is described under [Round to the next period](#afronden-naar-de-volgende-periode).
</Step>
<Step>
### Save [#sla-op]
Click **Save settings**. With **Remove period** you remove a period. With **Cancel** you reset the form to the saved list.
</Step>
</Steps>

If you have not added any periods yet, it says **No rent periods configured**. In an occupancy's form you then cannot choose a rent frequency.

## Where you see the periods [#waar-zie-je-de-periodes-terug]

In an occupancy's form the list is under **Rent frequency**, with **No frequency** at the top. A period of 1 month is called **Monthly** there. A period of 12 months shows as **Year (Jan - Dec)**, with the first and last month of your period. Other durations show as **6 months (Apr - Sep)**. If you entered a **Label** for a period, that label is shown instead of that text, in the list and in the **Rent frequency** column of the occupancies.

If you remove a period from the settings, occupancies already created with it keep their rent frequency.

## Round to the next period [#afronden-naar-de-volgende-periode]

The tick decides the initial state of **Round to next period boundary** on the invoice line with which you extend an occupancy. On the invoice line you can still switch the tick on or off yourself.

- If the tick is on, the line ends at the next period boundary. If you start in the middle of a period, the first part is charged pro rata. After that the customer follows the same cycle as the other tenants.
- If the tick is off, the line lasts exactly one period from the start date.

See [Create and edit invoices](/facturen/aanmaken-en-bewerken) and [Occupancies](/bezettingen).

## See also [#zie-ook]

<Cards>
  <Card title="Occupancies" href="/bezettingen" description="Link a customer to a pitch for the long term" />
  <Card title="Create and edit invoices" href="/facturen/aanmaken-en-bewerken" description="Round to next period boundary on an invoice line" />
</Cards>


# Access control settings (/en-GB/gebruikers/instellingen-toegangscontrole)

Under <UIPath>Support > Settings > Access control</UIPath> you set the behaviour of the barriers for number plates whose access period has expired.

<Requires permission="Instellingen bewerken" />

<DocScreenshot src="/screenshots/instellingen/settings-access-control.png" alt="Settings > Access control" />

## Let expired number plates exit [#verlopen-kentekens-laten-uitrijden]

A visitor with a number plate whose access period has expired otherwise cannot get through the exit barrier any more. With **Allow expired license plates to exit** the exit barrier opens anyway, during a grace period after expiry. That only works outside opening hours. If reception is open, staff deal with the vehicle at the desk.

The tick is on by default. If you switch it off, the exit barrier stays closed for an expired number plate.

| Setting | What it does |
|---|---|
| **Allow expired license plates to exit** | Switches the grace period on or off. |
| **Exit grace period (days)** | The number of days after expiry during which a vehicle can still leave outside opening hours. 2 by default, at most 30. With 0 there is no grace. |

The grace only applies to number plates at an exit. A number plate that is blocked or not active never gets grace. For other access methods, such as NFC tags or QR codes, there is no grace.

Opening hours come from <UIPath>Support > Settings > Opening hours</UIPath>. See [Opening hours](/gebruikers/organisaties#openingsuren).

## Save changes [#wijzigingen-opslaan]

At the bottom, click **Save settings**. With **Cancel** you reset the form to the saved values.

## See also [#zie-ook]

<Cards>
  <Card title="Access control" href="/toegangscontrole" description="Access points, vehicles and log" />
  <Card title="Organisation" href="/gebruikers/organisaties" description="Opening hours and other settings" />
</Cards>


# Microsoft Entra groups (/en-GB/gebruikers/microsoft-entra)

With provisioning, Microsoft Entra ID sends your users and groups to Tillor. If you link an Entra group to a Tillor [group](/gebruikers/groepen), the members of that group follow Entra: anyone you add in Entra gets the group's tasks and views, and anyone you remove or disable loses them. Nobody has to sign in again for this.

Entra uses the SCIM protocol for this. Tillor itself reads nothing from your Microsoft tenant: Entra decides which users and groups it sends. Only during [Quick setup](#snel-instellen) does your browser talk to Microsoft to create the app for you.

## What does and does not happen [#wat-er-wel-en-niet-gebeurt]

- **Existing members only.** Entra does not create Tillor accounts. Someone who is not yet a member of your organisation does not count until you [invite](/gebruikers/organisaties) that person. As soon as they become a member, they are immediately in their linked groups
- **No data of non-members.** For people without a Tillor account, Tillor stores no name or email address, only an unreadable code that lets Tillor recognise them if they become a member later
- **Nothing without a link.** An Entra group only changes something in Tillor once you link it to a Tillor group under **Entra groups not linked**
- **One to one.** A Tillor group belongs to at most one Entra group
- **The name stays Tillor's.** If you rename the group in Entra, you see the new name after **Entra ·**, but the Tillor group keeps its own name
- **Nested groups** are not expanded. A group that is a member of another group does not count as a member. If you want those people too, assign the nested group separately in Entra and link it to the same or another Tillor group
- **Signing in does not change.** People simply sign in with Microsoft, see [Sign-in](/inloggen)

## Before you start [#voordat-je-begint]

You need:

- In Tillor, the **Edit settings** permission
- In Microsoft Entra, the **Cloud Application Administrator** or **Application Administrator** role (or higher)
- An Entra licence that allows automatic provisioning to custom apps (Microsoft Entra ID P1 or higher)

Make sure your colleagues have the same Microsoft account or the same email address in Tillor as in Entra. That is how Tillor recognises who is who, see [How Tillor recognises people](#hoe-tillor-mensen-herkent).

## Quick setup [#snel-instellen]

If you are an Entra administrator yourself, Tillor sets up the link for you in one go.

1. Go to **Support > Settings** and choose **Groups**
2. Under **Microsoft Entra**, click **Set up with Microsoft** and then **Sign in and set up**
3. In the Microsoft window, sign in with your administrator account and give consent. Microsoft asks for permission to manage apps and provisioning and to read your groups

Tillor then creates the app in Entra, fills in the tenant URL and the token, has users recognised by their Microsoft account and has Entra send the type of each group along. After that the synchronisation starts and Tillor immediately sends you and all your groups, so you do not have to wait for the first synchronisation. Finally, Tillor reads the type of each group and whether a Team belongs to it. You see each step being ticked off. Tillor does this in the background: you can close the window or even the page. If you click **Set up with Microsoft** again later, you see how far it is, or for up to an hour after it finished whether it succeeded or failed. After that you can start again with **Set up again**.

Entra sends all your users and groups in the process. You do not have to choose anything beforehand: the groups appear under **Entra groups not linked** and change nothing until you link them. To do so, continue at [Link groups in Tillor](#groepen-koppelen-in-tillor). The members of the groups follow with the first synchronisation. That takes a few minutes, and a few hours for large organisations.

<Callout type="info">
Tillor only uses the access for this setup. It goes encrypted to the background task and is not stored anywhere afterwards; Microsoft lets it expire by itself after about an hour. If you go through **Set up with Microsoft** again, Tillor finds the same app again and does not create a second one.
</Callout>

<Callout type="warn">
Quick setup creates a new token. A token you pasted into Entra by hand earlier stops working afterwards. If the setup stops halfway, click **Retry**.
</Callout>

If signing in does not work, for example because your organisation blocks consent for apps, or if you want Entra to send only certain groups, set up the link by hand as described below.

## Manual setup [#handmatig-instellen]

<Steps>
<Step>

### Create a token in Tillor [#token-maken-in-tillor]

1. Go to **Support > Settings** and choose **Groups**
2. At the top is **Microsoft Entra**. If the link is already set up, click **Connection**
3. Copy the **Tenant URL**. It looks like `https://…/api/orgs/<organisatie>/scim/v2`
4. Click **Generate token** and copy the token that appears

<Callout type="warn">
The token is shown only once. Paste it into Entra straight away. If you lose it, click **Replace token** and use the new token.
</Callout>

</Step>
<Step>

### Create an app in Entra [#een-app-maken-in-entra]

1. Open the [Microsoft Entra admin centre](https://entra.microsoft.com)
2. Go to **Identity > Applications > Enterprise applications** and click **New application**
3. Click **Create your own application**
4. Give the app a name, for example **Tillor**, choose **Integrate any other application you don't find in the gallery (Non-gallery)** and click **Create**

If you already have an enterprise application for Tillor, you can use that too.

</Step>
<Step>

### Connect provisioning [#provisioning-koppelen]

1. In the app, open **Provisioning** and click **Get started** (or **New configuration**)
2. Set **Provisioning Mode** to **Automatic**
3. Under **Admin Credentials**, enter:
   - **Tenant URL**: the Tenant URL from Tillor
   - **Secret Token**: the token from Tillor
4. Click **Test Connection**. Entra must report that the connection succeeded
5. Click **Save**

</Step>
<Step>

### Check the attributes [#attributen-controleren]

Under **Mappings**, open the **Provision Microsoft Entra ID Users** line:

- Set **externalId** to **objectId** (by default it says **mailNickname**). Tillor then recognises someone by their Microsoft account, even if the email address differs
- Leave **userName** (← **userPrincipalName**), **active** and **emails[type eq "work"].value** (← **mail**) as they are

Leave **Provision Microsoft Entra ID Groups** switched on. The default settings (**displayName**, **externalId** ← **objectId**, **members**) are fine.

If you want to see in Tillor what kind of group it is, add these attributes to the groups. Under **Show advanced options**, first choose **Edit attribute list for customappsso** and add the target attributes, then **Add New Mapping** for each line:

| Source in Entra | Target attribute | Type |
|---|---|---|
| Expression `Join(",", [groupTypes])` | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:groupTypes` | String |
| **securityEnabled** | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:securityEnabled` | Boolean |
| **mailEnabled** | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:mailEnabled` | Boolean |
| **onPremisesSyncEnabled** | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:onPremisesSyncEnabled` | Boolean |
| **mail** | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:mail` | String |
| **description** | `urn:ietf:params:scim:schemas:extension:tillor:2.0:Group:description` | String |

If a source is missing from Entra's list, skip that line. Entra cannot send whether a Team belongs to a group this way; Tillor only sees that through **Set up with Microsoft**.

You may leave other attributes as they are. Tillor does not store them.

</Step>
<Step>

### Assign groups [#groepen-toewijzen]

1. In the app, open **Users and groups** and click **Add user/group**
2. Choose the groups Tillor should receive, for example **Reception**, and click **Assign**
3. Under **Provisioning > Settings**, check that **Scope** is set to **Sync only assigned users and groups**

Entra sends a group together with its members. You do not have to assign the members separately.

</Step>
<Step>

### Start provisioning [#provisioning-starten]

Under **Provisioning**, set **Provisioning Status** to **On** and click **Save**.

The first round can take a while, depending on the number of users. After that Entra sends the changes about every 40 minutes. If you want to update one person immediately, use **Provision on demand** in Entra.

</Step>
<Step>

### Link groups in Tillor [#groepen-koppelen-in-tillor]

Refresh **Settings > Groups**. At the top is the **Microsoft Entra** line with the last synchronisation and how many groups are linked. Below your Tillor groups is **Entra groups not linked** with the groups that were sent but do nothing yet. Click **Show** if the list is closed and use the search field to find a group. For each group, choose under **Link to…** what should happen and then click **Save**. With **Revert** you discard your choices. A Tillor group can only be attached to one Entra group; groups that are already linked cannot be chosen again.

| Choice | What happens |
|---|---|
| **Create new** | Tillor creates a group with the name from Entra and fills it with the recognised members |
| An existing group | The members of that group are replaced by the recognised members from Entra. If Entra has not yet sent the members of that group, the current members stay until the synchronisation delivers them |

From now on, Entra updates the members at every synchronisation. The linked group disappears from the list, and in your Tillor groups it says **Entra · [name]** under the group, with what kind of group it is.

Linking is only done from **Entra groups not linked**. A Tillor group you manage by hand, such as IT, is not linked from the group itself.

After each group name it shows what kind of group it is in Entra. With the buttons above the list you show only one kind.

| Label | What it is |
|---|---|
| **Security** | An ordinary security group, often the group you want to link |
| **Mail-enabled security** | A security group with an email address of its own |
| **Distribution list** | Only an email list |
| **Microsoft 365** | A group with a shared mailbox and a SharePoint site, sometimes with a Team |
| **Windows Server AD** | Comes from your local Active Directory (hybrid) and is managed there |
| **Dynamic** | Entra decides the members itself with a rule |
| **Teams** | A Team belongs to it |
| **Type unknown** | Tillor does not know the type yet. Go through **Set up with Microsoft** again |

SharePoint site groups, such as **Owners**, **Members** and **Visitors** of a site, are not Entra groups. They never reach Tillor. What you do see is the Microsoft 365 group behind the site.

</Step>
</Steps>

## How Tillor recognises people [#hoe-tillor-mensen-herkent]

For each user Entra sends, Tillor looks for an existing member of your organisation:

1. First by the **Microsoft account** the person signs in to Tillor with (the Entra object ID, if you set **externalId** to **objectId**)
2. Otherwise by **email address**: the work address from Entra, or the **userPrincipalName** if that is an email address

If Tillor finds nobody, or the user is disabled in Entra, they do not count in the group. As soon as the person becomes a member of the organisation, they count straight away. If you enable them again in Entra, they count at the next synchronisation.

## What happens when something changes in Entra [#wat-er-gebeurt-bij-wijzigingen-in-entra]

| In Entra | In Tillor |
|---|---|
| Member added to a linked group | Joins the Tillor group (if they are a member of the organisation) |
| Member removed from the group | Leaves the Tillor group |
| User disabled (**Account enabled** off) | Leaves all linked Tillor groups. Their Tillor account remains |
| User or group no longer assigned to the app | Entra sends a disable or delete, with the same effect |
| Group deleted | Under the Tillor group it says **Removed in Entra. Members were kept.** The Tillor group remains with its last members and is no longer updated |

Removing someone from your organisation altogether is done in Tillor, under [Organisation](/gebruikers/organisaties). Entra only manages the group members.

## What you see in the activity log [#wat-je-terugziet-in-het-activiteitenlog]

In the [activity log](/activiteitenlog) you see:

- Every change to the members of a Tillor group that Entra makes, with who joined or left. It is recorded in the name of the system, not of a user
- Every synchronisation round from Entra, one line per round. A round in which Entra sends nothing is not shown
- Who linked or unlinked an Entra group to a Tillor group, and who replaced the token

## Change or stop the link [#koppeling-wijzigen-of-stoppen]

- **Unlink**: on the Tillor group, click **Unlink**. The Tillor group stays as it is and you manage it by hand again. The Entra group comes back under **Entra groups not linked**
- **Another Tillor group**: unlink, then link the Entra group to another group under **Entra groups not linked**. The previous group keeps its members, but is no longer updated
- **Stop altogether**: in Entra, set **Provisioning Status** to **Off**, or delete the enterprise application

## Replace the token [#token-vervangen]

In the **Microsoft Entra** line, click **Connection** and then **Replace token** if the token has leaked or if you need it again. The old token stops working immediately. Paste the new token into Entra under **Provisioning > Admin Credentials > Secret Token** and click **Save**. Until you do, the synchronisation in Entra fails.

## Troubleshooting [#problemen-oplossen]

**Set up with Microsoft stops at a step**

The step shows Microsoft's message. Usually your account lacks the administrator role or the consent. Check the roles under [Before you start](#voordat-je-begint) and click **Retry**. Tillor reuses the app and provisioning that were already created.

**Test Connection fails**

Check that the Tenant URL was copied in full, including `/scim/v2`, and that the token is the one generated last. After **Replace token**, an old token no longer works.

**A group is not in the list**

Wait until the first synchronisation is done and refresh the page. If you set up the link by hand, Entra only sends groups that are assigned to the app: check **Users and groups** in the app and wait for the next round, or use **Provision on demand**.

**Someone is missing from the Tillor group**

- Is that person a member of your Tillor organisation? Entra does not create accounts
- Does the email address in Entra match the one in Tillor? Otherwise set **externalId** to **objectId**, so that Tillor recognises them by their Microsoft account. That only works if they have already signed in to Tillor with Microsoft once
- Is the user enabled in Entra?
- Are they a direct member of the group, and not through a nested group?

**My manual change disappears**

For a linked group, Entra is the source. Change the members in Entra, or unlink the group.

**More details about a failed round**

In Entra, open **Provisioning > Provisioning logs**. There you see for each user and group what Entra tried and what answer Tillor gave.

## See also [#zie-ook]

<Cards>
  <Card title="Groups" href="/gebruikers/groepen" description="Create and use groups" />
  <Card title="Views" href="/taken/weergaven" description="Share a task view with a group" />
  <Card title="Sign-in" href="/inloggen" description="Sign in with Microsoft" />
</Cards>


# Organisation (/en-GB/gebruikers/organisaties)

On the **Settings** page (at the bottom of the main menu, <UIPath>Support > Settings</UIPath>) you manage your organisation's settings. On the left you switch between the sections. Which sections you see depends on your permissions.

| Section | What for |
|---|---|
| **General** | Organisation profile, time zone, default country and brand colours. See [General](#algemeen) |
| **Opening hours** | Weekly schedule, seasons, exceptions and public holidays. See [Opening hours](#openingsuren) |
| **Invoicing** | PDF, payment term and VAT rates. See [Invoicing settings](/gebruikers/instellingen-facturatie) |
| **Printing** | Printers and print times. See [Printing](#afdrukken) |
| **Payments** | The Others payment method and sender address. See [Payment settings](/gebruikers/instellingen-betalingen) |
| **Occupation** | Rent frequencies for occupancies. See [Set up rental periods](/gebruikers/instellingen-huurperiodes) |
| **Terrain tariff** | The formula for the calculated tariff. See [Tariff formula](/terreinen#tariefformule) |
| **Access Control** | Leaving with an expired number plate. See [Access control settings](/gebruikers/instellingen-toegangscontrole) |
| **Map** | Map centre and map direction. See [Set the map default](/kaart#kaartstandaard-instellen) |
| **Terrain types** | Types for terrains. See [Terrain types](/terreinen#terreintypes) |
| **Task labels** | Labels for tasks. See [Labels](/taken/labels) |
| **Groups** | Bundle colleagues. See [Groups](/gebruikers/groepen) |
| **Custom fields** | Extra fields on customers, terrains and more. See [Custom fields](/eigen-velden) |
| **Apple Wallet** | Pass background and access point. See [Apple Wallet](#apple-wallet) |
| **Tablets & kiosks** | Tablets and kiosks. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken) |
| **Integrations** | Links with other services. See [Integrations](#integraties) |
| **Users** | Members, invitations and permissions. See [Manage user permissions](#gebruikersrechten-beheren) |

<Callout type="info" title="Good to know">
- Which sections you see depends on your permissions. You save changes at the bottom with **Save settings**
- About a week before a public holiday, Tillor emails the support address if the opening hours for that day are still empty
- After you save the wallet settings, Tillor updates all active wallet passes again. Visitors usually see that after opening the pass
- Once your organisation has invoices or payments, the currency can no longer change
</Callout>

<Callout type="info">
Company details on invoices (name, address, VAT number, IBAN, logo) are set during onboarding. Contact Tillor support if you want to change them.
</Callout>

## Integrations [#integraties]

Choose **Integrations** to see the available links, such as Voys telephony, bank accounts, Mollie or accounting software (e.g. Admisol). Under **Integrations** in the left-hand menu are categories (communication, payments, accounting, meters). Click an integration in the list to open its detail page. There you install the link or adjust its settings (no separate dialog). See also the [overview of integrations](/integraties).

<DocScreenshot src="/screenshots/communicatie/providers/marketplace-overview.png" alt="Settings - integrations overview" />

## General [#algemeen]

Under **General** you set the organisation profile, the time zone, the default country and the brand colours. You need the **Edit settings** permission to save changes.

## Opening hours [#openingsuren]

Under **Opening hours** you edit one weekly schedule. With the coloured options you switch to **seasonal periods** (for example 1 July to 31 August) or an **exception** (a single date or a period such as 24 to 26 December). **Public holidays** for the coming 12 months are already there: choose a holiday and enter the hours (or leave them empty if you are closed that day). Leave a weekday empty if you are closed that day. The inbox AI uses these hours as office opening hours. About a week before a public holiday, Tillor sends a reminder email to the organisation's **support address** (or the general email address if there is no support address) when the hours for that holiday have not been filled in yet. If you use Partoo, the opening hours are synchronised automatically. See [Partoo](/integraties/partoo). A website can fetch the resolved hours (including season labels such as Summer or Winter) and upcoming holidays through the [Opening hours API](/ontwikkelaars/voorbeelden/opening-hours).

## Printing [#afdrukken]

Under **Printing** you set PDF printing, printer IP addresses and the **print times schedule**. For each weekday, add one or more times (or leave the day empty). Online, mandate and bank transfer payments wait for the next time that day before the invoice goes to the printer queue.

## Apple Wallet [#apple-wallet]

Under **Apple Wallet** you set two things side by side: the **pass background** on the left, the **access point location** on the right.

**Pass background** (left): optional full-bleed photo for the Poster Generic layout on iPhone with **iOS 27**. Upload JPEG, PNG or WebP; large files are reduced automatically. Drag on the preview to choose which part of the photo stays visible behind the QR code. The preview shows your choice immediately; only after **Save** at the bottom of **Settings** does the photo (or its removal) go live, and Tillor passes the focus on to access passes.

On iPhone with **iOS 26 or older**, the pass uses the classic generic layout with the same data (status, visitor name, validity, QR code). Without an image of your own, all passes get the default Tillor gradient background. With a photo of your own, the **organisation logo** from your company details is at the top, in colour on the photo. On the default gradient, the logo is white on the dark gradient.

On Poster Generic passes (iOS 27) the QR code is **square**; on older devices it is rectangular, as on a classic generic pass.

**Access point location** (right): click on the map or drag the pin to set the GPS point of the main access point. **Apple Wallet** and **Google Wallet** use that location on the access pass. On iPhone, iOS can suggest the pass on the lock screen when a visitor is nearby. Choose **Use park map centre** to remove the pin and use the centre of the park map.

After you save **Settings**, Tillor updates all active wallet passes in the organisation (Apple through silent push, Google through object sync). Guests usually see the update after opening the pass in Wallet; sometimes a manual refresh in the Wallet app is still needed. The preview in Tillor shows the same cropping as on the pass: drag the image so that the centre is where you want it.

<DocScreenshot src="/screenshots/gebruikers/settings-wallet-barrier-map.png" alt="Settings > Apple Wallet with pass background and access point on the map" />

On the back of the wallet pass are the organisation's phone number and email address (the support email if one is set, otherwise the general address). For blocked, expired or revoked passes, those details also appear behind the reception text on the lock screen (Apple) or in Google Wallet.

<DocScreenshot src="/screenshots/gebruikers/settings-dialog.png" alt="Settings > General" />

## Manage user permissions [#gebruikersrechten-beheren]

Under **Users** you see the **Members** of your organisation and the **Pending invitations**. How you invite and remove colleagues and set their notifications is described under [Invite users and give permissions](/gebruikers/gebruikers-en-rechten).

### Edit permissions [#rechten-bewerken]

Click **Edit permissions** on a user. The full explanation, including groups and blocked permissions, is under [Edit permissions](/gebruikers/gebruikers-en-rechten#rechten-bewerken). Below are the permissions that often raise questions.

### Bank accounts [#bankrekeningen]

| Permission | What may the user do? |
|---|---|
| **View bank transactions** | The **Administration > Bank transactions** page and the **Bank account transactions** block on **Administration > Payment reports** |
| **Sync bank transactions** | The **Sync bank account** button (manual import) |

The permissions are in the permissions dialog under the **Bank transactions** group.

See also [Bank accounts](/boekhouden/betalingsrapporten/betaalmethodes/ponto) for the open banking link.

### Assign payment [#betaling-koppelen]

| Permission | What may the user do? |
|---|---|
| **Assign payment** | **Assign payment** on a booked invoice, **Assign** on payment groups and **Assign to invoice** on bank transactions (not visible without the permission) |

The permission is in the permissions dialog under the **Payments** group.

### OAuth apps [#oauth-apps]

| Permission | What may the user do? |
|---|---|
| **Authorize OAuth apps** | Give third parties (e.g. Cursor, Claude, ChatGPT) permission through OAuth, and keep using existing OAuth tokens |

Existing users keep the permission after the migration. New users do not get it automatically. Tick it in the user's permissions dialog. Switch it off to prevent that user from linking new OAuth apps; that user's existing tokens then stop as well. Users with this permission in at least one organisation may authorise.

See also [MCP](/ontwikkelaars/mcp).

## Data processing agreement [#verwerkersovereenkomst]

If a **Data Processing Agreement Required** screen appears instead of Tillor, your organisation must sign the current data processing agreement (DPA) before you can continue. You can first download the document with **Download DPA Document**. Then you request a verification code. It is sent by text message to the phone number of the responsible person. Enter the code and click **Accept DPA**.

## Details on invoices [#gegevens-op-facturen]

Company details such as name, address, VAT number and IBAN appear automatically on invoices. They are set during onboarding. Contact Tillor support to change them.

## See also [#zie-ook]

<Cards>
  <Card title="Users" href="/gebruikers" description="Manage account access" />
  <Card title="Groups" href="/gebruikers/groepen" description="Bundle colleagues, including with group permissions" />
  <Card title="Invoices" href="/facturen" description="Create and send invoices" />
</Cards>


# Evidence and validity (/en-GB/handtekeningen/bewijs-en-geldigheid)

For every signing, Tillor records who signed, when and how, and seals the PDF so that any later change is visible. The result is a simple electronic signature, suitable for rental contracts, house rules, waivers and terms. For documents where the law requires a stronger signature, Tillor is not the right place.

## What is on the evidence pages? [#wat-staat-er-op-de-bewijspaginas]

The signed PDF gets one or more **Signing evidence** pages at the end. They show:

- the title of the document, the request, your organisation, the number of pages and when the request was created, sent and completed
- two fingerprints of the file: of the PDF as you uploaded it, and of the signed pages before the evidence pages were added. If a single character in the file changes, the fingerprint no longer matches
- per signer: name, role, type, email address, phone number and language, when the link went out and when that person first opened the page, the time of signing, the IP address and the device
- how the signer was confirmed: with a one-time code, which channel the code went to and when, or signed in to Tillor for staff
- the sentence the signer agreed to, exactly as it appeared on screen
- what the signer filled in: every text, date and checkbox field with its value, including what was left empty
- the signature and the initials as they were drawn, and on which pages they appear. A typed signature appears as an image of the typed name, just like a drawn one
- how the signing was done: on the signing page via the link, in Tillor by a signed-in staff member, or on the tablet at reception (with a code, or with the identity confirmed by a staff member)
- the **audit trail**: every step with time, who and from which IP address and device. For example *Signing link sent*, *Signing page opened*, *Verification code sent*, *Wrong code entered*, *Signed* and *Completed and sealed*

Times are shown in your organisation's time zone, with the UTC time (the worldwide standard time) next to it. Tillor stores IP addresses and devices encrypted. You can see them in Tillor and on the evidence pages. The signatures and filled-in values appear in the document at the places you chose. Your original upload is stored separately and never changes.

You see the same steps on the request page under **History** and on the customer under **Events**.

<Callout type="info" title="For the technical reader">
The two fingerprints are SHA-256 checksums. A SHA-256 fingerprint changes completely as soon as a single byte of a file changes, which is why it proves the file has not been altered. The evidence page also shows the fingerprint of the sealing certificate (see below).
</Callout>

## Seal and timestamp [#zegel-en-tijdstempel]

As the last step, the signed PDF is **sealed** with a digital signature of your organisation, created by Tillor. If you open it in Adobe Reader or another PDF reader, you see a signature panel. If anything about the file changes after sealing, the reader reports it.

The reader may call the signer **unknown** or **not trusted**. That is normal: the certificate comes from Tillor and not from a paid certificate authority. Which certificate it is appears with its fingerprint on the evidence page.

The seal also gets a **timestamp** from an independent, free timestamp service (FreeTSA, or DigiCert if that one does not respond). This proves, independently of Tillor, when the file existed in exactly this form. The time appears on the request page under **Timestamp**.

## What kind of signature [#welk-soort-handtekening]

This is a **simple electronic signature** under the European eIDAS rules. Tillor checks the email address or phone number with a code, records the drawing and keeps the evidence. That suits rental contracts, house rules, waivers and terms.

A **qualified** signature, for example with itsme or an eID card, is not possible. If you have a document for which the law requires that, have it signed outside Tillor.

## What happens to the evidence? [#wat-gebeurt-er-met-het-bewijs]

- The original PDF and the signed PDF stay with the customer's documents. You can archive them but not delete them.
- The evidence is part of the signed PDF. Anyone who received a copy therefore also has the evidence pages.
- The audit trail stays on the request page, even if the request was declined, canceled or has expired.

## Problems? [#problemen]

<Accordions>
<Accordion title="My PDF reader says the signature is not trusted">
That is correct and normal. The seal comes from Tillor, not from a paid certificate authority. What matters is that the reader does not report a change after sealing. The certificate appears with its fingerprint on the evidence page.
</Accordion>
<Accordion title="My PDF reader reports that the document was changed after signing">
The file was modified after sealing, for example by saving it again or editing it. Download the signed PDF again from the request's detail page or from the customer's documents. That file is unchanged.
</Accordion>
<Accordion title="A customer wants a qualified signature with itsme or eID">
That is not possible in Tillor. Have that document signed outside Tillor.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="How someone signs" href="/handtekeningen/ondertekenen" />
  <Card title="Following up a request" href="/handtekeningen/opvolgen" />
  <Card title="All terms" href="/begrippen" />
</Cards>


# Requesting signatures (/en-GB/handtekeningen/handtekening-vragen)

With a signing request, you let one or more people sign a PDF online. You make it in two parts: first you choose the customer and the PDF, then you set up the signers and fields in the editor. How to follow who has signed afterwards is covered in [Following up a request](/handtekeningen/opvolgen).

<Requires permission="Manage signature requests" />

Before you start:

- You need the **Manage signature requests** permission. If you do not have it, the **Request signatures** button is greyed out.
- The file must be a PDF, up to 250 MB. Tillor rejects any other file type with **This is not a PDF. Choose a PDF file.**
- Every signer needs an email address or phone number to receive the link or code. For a customer or contact, fill that in first in their details.
- Every signer needs at least one signature or initials field.

## Making a signing request [#een-ondertekenverzoek-maken]

<Steps>
<Step>
### Start the request [#start-het-verzoek]
Choose where you start.

<Tabs items={["From Signatures", "From the customer"]}>
<Tab value="From Signatures">
Go to <UIPath>Administration > Signatures</UIPath> and click **Request signatures**. Choose the **Customer**.
</Tab>
<Tab value="From the customer">
Open the **Documents** tab of the customer and click **Request signatures**. The customer is already filled in.
</Tab>
</Tabs>

Under **Document**, choose a PDF that is already with that customer, or leave **Upload a new PDF** selected and drag the PDF into the box (or click **Choose PDF**). Enter a **Title**, for example *Rental contract 2027*. If you leave it empty, Tillor uses the name of the document. Then click **Continue**.

<DocScreenshot src="/screenshots/handtekeningen/signatures-create-dialog.png" alt="Request signatures dialog with customer, title and document" />

An uploaded PDF is added to the customer's documents. Tillor never changes it: the signatures go on a separate copy.
</Step>
<Step>
### Add signers [#voeg-ondertekenaars-toe]
Under **Signers**, click **Add signer** and choose:

- **Customer: [name]**
- **Contact of the customer**
- **Staff member**
- **External party**: fill in **Name**, **Email address** and/or **Mobile number** and **Language**. At least one of the two contact details is required. Without an email address, the person gets the link by text message.

<DocScreenshot src="/screenshots/handtekeningen/signatures-add-signer-menu.png" alt="Add signer menu" />

<DocScreenshot src="/screenshots/handtekeningen/signatures-external-dialog.png" alt="Add external party dialog" />

You can add up to 10 signers. They sign from top to bottom, and the next one only gets the link once the previous one has signed. With **Sign earlier** and **Sign later** (the arrows) you change the order, and with the bin icon you remove someone. In the box below the name you can optionally enter a **Role**, for example *Tenant* or *Guarantor*.

Every signer gets their own colour. You see that colour again on their fields in the document.
</Step>
<Step>
### Place the fields [#plaats-de-velden]
Under **Fields for**, choose the signer you are placing fields for. Then choose the type of field and tap or drag on a page of the document. Drag a field to move it and drag the corner to make it larger or smaller.

<DocScreenshot src="/screenshots/handtekeningen/signatures-editor.png" alt="Editor with signers, Fields for and the field types" />

| Field | What the signer does |
| --- | --- |
| **Signature** | Places the drawn signature by tapping the box |
| **Initials** | Places the drawn initials by tapping the box |
| **Name** | Nothing: Tillor fills in the signer's name |
| **Date signed** | Nothing: Tillor fills in the day of signing |
| **Text** | Types one line, up to 200 characters, for example a number plate |
| **Long text** | Types a few lines, up to 2,000 characters, for example a remark |
| **Checkbox** | Ticks a condition |
| **Date** | Picks a date, for example an arrival day |

Click a placed field to select it. Below the buttons you then see:

- **Signer**: assigns the field to another signer, without drawing it again.
- For **Text**, **Long text**, **Checkbox** and **Date** also a **Question or label** (the signer sees it at the input box) and **Required**. A field that is not required may stay empty.
- The cross on the field deletes it.

<DocScreenshot src="/screenshots/handtekeningen/signatures-editor-fields.png" alt="Last page with the fields of the tenant, the co-tenant and the landlord, each in their own colour" />

If someone needs initials on every page, use **Initials on every page**. Tillor then places an initials field on all pages for that signer. As long as a signer has no signature or initials field, you see **No signature field yet** next to that person.
</Step>
<Step>
### Set the message and deadline [#stel-bericht-en-termijn-in]
Under **Request**, fill in:

- **Title**: as the signers see it.
- **Message to the signers**: optional, it appears in the email and on the signing page.
- **Sign before**: the final date. By default this is 14 days after creation. Signing is possible until the end of that day.
- **Reminder after**: after how many days (1 to 14) a signer whose turn it is gets a reminder. 3 days by default.
</Step>
<Step>
### Send the request [#verstuur-het-verzoek]
Click **Send** and confirm. The first signer gets the link.

<DocScreenshot src="/screenshots/handtekeningen/signatures-send-dialog.png" alt="Confirmation Send the request?" />

If you want to continue later, click **Save draft**. With the bin icon next to it (**Delete draft**) you discard the request, after confirmation. The PDF stays with the customer's documents.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The request gets the status <Status tone="info">In progress</Status>. You find it on the customer under **Documents** and under <UIPath>Administration > Signatures</UIPath>. Tillor reports **Sent to the first signer**.
- The first signer gets an email with a personal link, or a text message if there is only a phone number. Each following signer gets the link as soon as the previous one has signed.
- A signer whose turn it is and who does not respond automatically gets a reminder after the number of days under **Reminder after**, up to 2 times. You can always send a reminder yourself, see [Following up a request](/handtekeningen/opvolgen#een-herinnering-sturen).
- As soon as everyone has signed, the request becomes <Status tone="success">Completed</Status> and the signed PDF is with the customer.
- If the deadline passes before everyone has signed, the request becomes <Status tone="warning">Expired</Status>.

If you want to change something while nobody has signed yet, or only you have, click **Back to editing**. The request becomes a draft again: the links that were sent stop working and everyone signs again once you send it again. If someone else has already signed, cancel the request and make a new one.

Do you want an automation to react to a completed request, for example with a task? Use the trigger **Signature request completed**, see [Triggers](/automatiseringen/triggers).

## Problems? [#problemen]

<Accordions>
<Accordion title="The Request signatures button is greyed out">
You are missing the **Manage signature requests** permission. Ask an administrator to add it under <UIPath>Settings > Users</UIPath>.
</Accordion>
<Accordion title="Tillor says: This is not a PDF. Choose a PDF file.">
You chose another file type, for example Word. Save the document as a PDF first and choose that file.
</Accordion>
<Accordion title="Tillor says: Choose a customer, or: Upload a PDF or pick one of the customer's documents">
On the first screen, **Customer** or **Document** is empty. Fill in both and click **Continue** again.
</Accordion>
<Accordion title="I cannot send">
Tillor checks the request before it goes out and tells you what is missing:

- **Add at least one signer before sending.**
- A signer has no signature or initials field yet. Tillor selects that person. Then drag on the document to place a field.
- A signer has no email address or phone number and so cannot receive a link or code. That also applies to a customer or contact: first fill in an email address or phone number in their details. In the list, such a person shows **No email address or phone number**.
- **Give the request a title.**
</Accordion>
<Accordion title="Tillor says: The request could not be sent">
The request may not have gone out. Reload the page. If the request is still a <Status>Draft</Status>, click **Send** again.
</Accordion>
<Accordion title="Tillor says: The draft could not be saved">
Your changes were not saved. Reload the page and check what is still there before you continue.
</Accordion>
<Accordion title="The document does not load in the editor">
Reload the page. If that does not help, check that the file is a valid PDF.
</Accordion>
<Accordion title="I put a field with the wrong person">
Click the field and choose the right person under **Signer**. The field stays where it is.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Following up a request" href="/handtekeningen/opvolgen" />
  <Card title="How someone signs" href="/handtekeningen/ondertekenen" />
  <Card title="Evidence and validity" href="/handtekeningen/bewijs-en-geldigheid" />
</Cards>


# Overview (/en-GB/handtekeningen)

With **Signatures** you have a PDF such as a rental contract, house rules, a waiver or a guarantee signed online. The signers sign one after another, and you decide where on the pages each signature, initials field or input box goes. How to go about it is covered in [Requesting signatures](/handtekeningen/handtekening-vragen).

When everyone has signed, Tillor makes a signed PDF with evidence pages at the end. It then appears in the customer's **Documents** and every signer receives a copy. Your original PDF is kept unchanged.

<Requires permission="Manage signature requests" />

Preparing, sending, reminding, withdrawing and canceling signing requests requires the **Manage signature requests** permission, in the **Signatures** group under <UIPath>Settings > Users</UIPath>. If you do not have that permission, those buttons are greyed out. All users in your organisation can view requests and sign themselves when it is their turn.

<Callout type="info" title="Good to know">
- A request has at most 10 signers and only PDF files, up to 250 MB.
- By default, people can sign for 14 days, until the end of the last day. You can choose another date.
- A signer whose turn it is gets a reminder after 3 days by default (you can choose 1 to 14 days), with a maximum of 2 automatic reminders. These go out with Tillor's daily check.
- When signing, the signer confirms with a 6-digit code. The code is valid for 10 minutes and a new one can be requested after 2 minutes.
- Your original PDF never changes. You can archive the original and the signed PDF but not delete them, because they are the evidence.
- The request gets the status Expired during the daily check, not at the exact moment the deadline passes.
</Callout>

## Where to find it [#waar-vind-je-het]

- <UIPath>Administration > Signatures</UIPath> shows all signing requests with their status and how many signatures are already in place.
- On a customer's profile, the **Documents** tab has the **Request signatures** button, with the customer's **Signature requests** below it.

<DocScreenshot src="/screenshots/handtekeningen/signatures-list.png" alt="List of signing requests under Administration > Signatures" />

## How does this fit together? [#hoe-hangt-dit-samen]

A signing request always belongs to one customer and one PDF. The signers do not have to be the customer: a contact, a colleague or an external party can also sign.

```mermaid
flowchart LR
  A[PDF bij de klant] --> B[Ondertekenverzoek met ondertekenaars en velden]
  B --> C[Ondertekenaar 1 tekent]
  C --> D[Ondertekenaar 2 tekent]
  D --> E[Ondertekende PDF met bewijspagina's]
  E --> F[Documenten van de klant]
  E --> G[Kopie voor elke ondertekenaar]
```

## How a request progresses [#hoe-een-verzoek-verloopt]

```mermaid
flowchart LR
  A[Concept] -->|Versturen| B[Bezig]
  B -->|iedereen getekend| C[Afgerond]
  B -->|ondertekenaar weigert| D[Geweigerd]
  B -->|Aanvraag annuleren| E[Geannuleerd]
  B -->|termijn voorbij| F[Verlopen]
  B -->|Terug naar bewerken| A
```

## Statuses [#statussen]

| Status | Meaning |
|---|---|
| <Status>Draft</Status> | You are still preparing the request. Nothing has been sent yet. |
| <Status tone="info">In progress</Status> | The request has been sent and people are signing. |
| <Status tone="success">Completed</Status> | Everyone has signed and the signed PDF is with the customer. |
| <Status tone="error">Declined</Status> | A signer declined. The request has stopped. |
| <Status>Canceled</Status> | You or a colleague withdrew the request. |
| <Status tone="warning">Expired</Status> | It was not signed in time. |

Per signer you see **Waiting** (not their turn yet), **Link sent** (their turn), **Signed** or **Declined**.

## Who can sign [#wie-kan-ondertekenen]

| Type | How that person signs |
|---|---|
| **Customer** | Via a personal link by email, or by text message if there is only a phone number |
| **Contact** | Like the customer, for a contact of that customer |
| **Staff member** | In Tillor itself, without a code |
| **External party** | Like the customer, with a name and an email address or phone number that you fill in yourself |

A customer, contact or external party can also sign at the desk, on a tablet with the Tillor app. See [On the tablet at reception](/handtekeningen/ondertekenen#op-de-tablet-aan-de-receptie).

## Automating [#automatiseren]

A signing request can start an [automation](/automatiseringen/triggers). With **Signature request completed** you can, for example, create a task as soon as a rental contract is signed, and with **Signature request changed** you react to every status change. You can also send the same events as a [webhook](/ontwikkelaars/webhooks) to your own system.

<Cards>
  <Card title="Requesting signatures" href="/handtekeningen/handtekening-vragen" />
  <Card title="Following up a request" href="/handtekeningen/opvolgen" />
  <Card title="How someone signs" href="/handtekeningen/ondertekenen" />
  <Card title="Evidence and validity" href="/handtekeningen/bewijs-en-geldigheid" />
  <Card title="Winning a seasonal customer" href="/praktijk/seizoensklant-binnenhalen" description="Have the rental contract signed" />
</Cards>

## Terms [#begrippen]

- **Signing request**: the assignment to have one PDF signed, with signers, fields and a deadline. See [signing request](/begrippen#ondertekenverzoek).
- **Signer**: someone who has to sign. A customer, contact, staff member or external party.
- **Field**: a place on the PDF where a signer signs, adds initials or fills something in.
- **Draft**: a request you are still preparing. Nothing has been sent yet.
- **Evidence pages**: the pages at the end of the signed PDF showing who signed, when and how. See [evidence page](/begrippen#bewijspagina).
- **Seal**: the digital signature of your organisation that closes the signed PDF. See [seal](/begrippen#zegel).


# How someone signs (/en-GB/handtekeningen/ondertekenen)

This page shows what your signers go through, so you can answer questions, and how to have someone sign at the desk on the tablet. You send out a request yourself via [Requesting signatures](/handtekeningen/handtekening-vragen).

Before you start:

- The request must have the status <Status tone="info">In progress</Status> and the signer must have their turn. If it is not yet anyone's turn, it says **Not your turn yet**.
- For the tablet you need the **Manage signature requests** permission and the Tillor app must be online on a device of your organisation.
- The signer needs a phone number or email address, because the code goes there. Only a staff member signs without a code.

## On the tablet at reception [#op-de-tablet-aan-de-receptie]

If someone is standing in front of you, they do not have to open the link themselves. This works for a customer, contact or external party whose turn it is.

<Steps>
<Step>
### Open the request [#open-het-verzoek]
Go to <UIPath>Administration > Signatures</UIPath> and open the request, or open it via the **Documents** tab of the customer.
</Step>
<Step>
### Click Sign on tablet [#klik-op-op-tablet-tekenen]
For the signer whose turn it is, click **Sign on tablet** and choose how the identity is confirmed:

- **With a code**: the signer confirms on the tablet with the code that arrives by text message or email, just like via the link.
- **Without a code**: you checked the identity at the desk, for example with an ID card. No code is asked for. The evidence sheet states that the identity was confirmed by a staff member, and the history shows who that was.

Tillor reports **Opened on the tablet**.
</Step>
<Step>
### Let the person sign [#laat-de-persoon-tekenen]
The document opens in the app on the tablet, with the signer's name at the top in large letters. Check that name together with the person in front of you. The steps are the same as via the link, see below. Right after sending, the tablet may briefly show **Preparing the document**.
</Step>
</Steps>

After signing or declining, the tablet returns to the home screen after a few seconds. With several signers, you send each one to the tablet separately when it is their turn. The evidence sheet states that the signature was placed on the tablet.

## What does the signer do? [#wat-doet-de-ondertekenaar]

<Tabs items={["Via the link", "On the tablet"]}>
<Tab value="Via the link">
The signer receives an email, or a text message if there is only a phone number. It contains a personal link to the signing page, with your message and the name of your organisation. The page works on a phone, tablet and computer, in the signer's language.
</Tab>
<Tab value="On the tablet">
The signer sees the document directly in the app, after you chose **Sign on tablet**. No link or email is needed. Someone who signs on the tablet with a code receives the code on their own phone or in their email.
</Tab>
</Tabs>

After that, the steps are the same.

<Steps>
<Step>
### Getting started [#beginnen]
The first card shows who else is signing, the place in the queue (for example *Signer 2 of 3*) and the steps. On the right is the document, with the signatures of earlier signers already in place. With **Start signing**, the signer begins. Every step has a back button. The phone's back button works too.

<DocScreenshot src="/screenshots/handtekeningen/signing-public-start.png" alt="Signing page for the guarantor with the start card and the document" />
</Step>
<Step>
### Draw your signature [#teken-je-handtekening]
The signer draws a **Signature** with a finger or mouse, or chooses **Type** and types their full name. Tillor then renders that typed name in a handwritten typeface. If there are initials fields, an **Initials** step follows in the same way (drawn or typed initials). With **Clear**, the signer starts again. Switching between **Draw** and **Type** empties the box.

<DocScreenshot src="/screenshots/handtekeningen/signing-public-type.png" alt="Draw your signature step with Type selected" />
</Step>
<Step>
### Place your signature [#plaats-je-handtekening]
The signer taps each marked box in the document (**Click to sign** or **Click to initial**). **Next field** jumps to the next empty box. With **Previous box** and **Next box**, the signer walks through all the boxes. A second tap on a filled box does nothing.
</Step>
<Step>
### Fill in your details [#vul-je-gegevens-in]
Only if you placed input boxes: text, date or a tick. Each box says **required** or **optional**. An empty required box blocks the step. What is typed appears in the document straight away. Tillor fills in the name and date of signing itself.
</Step>
<Step>
### Confirm and sign [#bevestig-en-onderteken]
The signer ticks that they have read the document. If anything is still missing, a list of buttons appears that jump to that step.

Only when everything is ready does the signer have a 6-digit code sent with **Send verification code**: by text message if there is a phone number, otherwise by email. The code is valid for 10 minutes. If it does not arrive, **Resend code** is available after 2 minutes. The signer then clicks **Sign** themselves. Signing never happens automatically.
</Step>
</Steps>

## What do you see afterwards? [#wat-zie-je-daarna]

- If it is not yet anyone's turn, it says **Not your turn yet** and a message follows when it is.
- Someone who has already signed sees **You signed** until the others are done.
- As soon as everyone has signed, each signer can download the signed PDF via the same link (**Signed by everyone**).
- For a withdrawn request, the signer sees **Request withdrawn**, for an expired request **Signing period ended** and for a declined request **Signing stopped**.
- A staff member signs in Tillor, via the **Sign now** button on the detail page or via the link in the message. A code is not needed, because that person is already signed in. Here too, the signature can be drawn or typed.

## Declining [#weigeren]

With **Decline to sign**, a signer can reject the request and optionally give a reason (up to 500 characters). The request then stops, nobody else is asked, and whoever created the request receives a message. See [Following up a request](/handtekeningen/opvolgen#wat-gebeurt-er-daarna).

## Problems? [#problemen]

<Accordions>
<Accordion title="The Sign on tablet button is missing">
The button only appears if the Tillor app on a device of your organisation has been in contact with Tillor in the last few minutes, and only for a customer, contact or external party whose turn it is. Open the app on the tablet, wait a moment and reload the page. Also check that **Show receipts and documents** is on in the [device settings](/mobiele-app/toestelinstellingen#kassabonnen-en-geluid). See also [Tablets and kiosks](/mobiele-app/tablets-en-kiosken).
</Accordion>
<Accordion title="Tillor says: Could not open it on the tablet">
Tillor could not reach a tablet that shows documents. Check that the app is open and that the device has a connection, and try again.
</Accordion>
<Accordion title="The signer does not receive a code">
The code goes to the phone number, or to the email address if there is no phone number. Ask the signer to check the spam folder and to use **Resend code** after 2 minutes. If the number or address is wrong, correct it on the customer or contact and send a reminder. For an external party, cancel the request and make a new one with the right details.
</Accordion>
<Accordion title="Tillor says: The code could not be verified">
The code entered is wrong or has expired. A code is valid for 10 minutes. The signer requests a new one with **Resend code** and enters it. Every wrong attempt appears in the history as **Wrong code entered**.
</Accordion>
<Accordion title="The signer cannot click Sign">
Something is still missing. Under **Still to do before you can sign:** it says what remains: drawing the signature or initials, tapping a box, or filling in a required box. The tick that the document has been read must also be on.
</Accordion>
<Accordion title="The link no longer works">
If the request was set back to draft, canceled or has expired, the old link no longer works. After sending again, the signer gets a new link. For a canceled or expired request, you need to make a new request.
</Accordion>
<Accordion title="The signer sees: This request has changed in the meantime">
The page was already open while the request changed, for example because it has already been signed. The page now shows where it stands. Nothing went wrong.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Following up a request" href="/handtekeningen/opvolgen" />
  <Card title="Evidence and validity" href="/handtekeningen/bewijs-en-geldigheid" />
  <Card title="Tablets and kiosks" href="/mobiele-app/tablets-en-kiosken" />
</Cards>


# Following up a request (/en-GB/handtekeningen/opvolgen)

After sending, you follow a signing request on its detail page: who has already signed, whose turn it is and what you can still do. This is also where you send a reminder, cancel a request and download the signed PDF.

Before you start:

- Anyone can view. Reminding, canceling, setting back and sending to the tablet require the **Manage signature requests** permission. Without that permission, those buttons are greyed out.
- The request must have been sent. A <Status>Draft</Status> is edited in the editor, see [Requesting signatures](/handtekeningen/handtekening-vragen).

## Opening the request [#het-verzoek-openen]

Open <UIPath>Administration > Signatures</UIPath>. For each request, the list shows the **Title**, **Customer**, **Status**, how many have already **Signed**, when it was **Created** and until when signing is allowed (**Sign before**). Search by title or customer name, or filter with **Status** on, for example, only the requests still in progress. Click a request to open it.

The same requests are also on the customer, on the **Documents** tab under **Signature requests**.

<DocScreenshot src="/screenshots/handtekeningen/signatures-customer-documents.png" alt="Documents tab of a customer with the signed PDF and the signing requests" />

## The detail page [#de-detailpagina]

On the left you see the request's details, the signers in order and the **History**. On the right is the document, with the signatures that have already been placed. At the top it says who the request is waiting for, for example *Waiting for Marc Janssens to sign.*

For each signer you see whether they still have to wait (**Waiting**), have received the link (**Link sent**), have **Signed** or **Declined**, with the time. The page refreshes by itself when someone signs.

### Before and after: from In progress to Completed [#voor-en-na-van-bezig-naar-afgerond]

This is what the same kind of request looks like while signing and afterwards. First it is <Status tone="info">In progress</Status>: the tenant has signed and the guarantor's turn is next.

<DocScreenshot src="/screenshots/handtekeningen/signatures-detail-in-progress.png" alt="Before: request in progress, the tenant has signed and the guarantor's turn is next" />

As soon as the last signer has signed, it is <Status tone="success">Completed</Status>. All signatures are in the document, the history has been extended and at the top is the button to download the signed PDF.

<DocScreenshot src="/screenshots/handtekeningen/signatures-detail-completed.png" alt="After: completed request with the signatures in the document and the history" />

## Sending a reminder [#een-herinnering-sturen]

For a signer whose turn it is, click **Send reminder**. That person receives the same link again, and Tillor reports **The link was sent again**. The link from the first message keeps working too. The button is not shown for staff members, who sign in Tillor, nor for signers who still have to wait.

Tillor also sends reminders itself. A signer whose turn it is gets a reminder after the number of days you set under **Reminder after** (3 by default), counted from the first message or the previous reminder. This happens at most 2 times per signer, and during Tillor's daily check. A reminder can therefore arrive up to a day later than the number of days you set.

## Having someone sign on the tablet [#laten-tekenen-op-de-tablet]

If the signer is at the desk, click **Sign on tablet** for that person. How that works and why the button is sometimes missing is covered in [On the tablet at reception](/handtekeningen/ondertekenen#op-de-tablet-aan-de-receptie).

## Signing yourself as a staff member [#zelf-ondertekenen-als-medewerker]

If a colleague or you yourself are next, that person receives a message with a link to Tillor. The detail page then shows the **Sign now** button.

<DocScreenshot src="/screenshots/handtekeningen/signatures-detail-staff-turn.png" alt="Request where the staff member's turn it is, with the Sign now button" />

## Canceling a request [#een-verzoek-annuleren]

Click **Cancel request** and confirm. The signing links then stop working and signatures that have already been placed are not used. If you want to continue after all, click **Keep**.

<DocScreenshot src="/screenshots/handtekeningen/signatures-cancel-dialog.png" alt="Confirmation Cancel this request?" />

Canceling is only possible while the request is <Status tone="info">In progress</Status>. A completed, declined or expired request is final.

## Back to editing [#terug-naar-bewerken]

If nobody has signed yet, or only you, the detail page shows **Back to editing**. The request becomes a draft again, links that were sent stop working and everyone signs again after sending. If someone else has already signed, the button is missing. Cancel the request then and make a new one.

## What happens next? [#wat-gebeurt-er-daarna]

- **Someone signs**: the signer gets the status **Signed** and the next one receives the link. The page refreshes by itself.
- **Everyone has signed**: you briefly see *Everyone signed. The signed PDF is being prepared.* The request becomes <Status tone="success">Completed</Status>. The signed PDF appears as **[title] (signed)** in the customer's **Documents**, with the same document type as the original PDF. If that had no type, it gets the type **Signed agreement**. Each signer receives a copy.
- **Someone declines**: the request stops with the status <Status tone="error">Declined</Status>. Whoever created the request gets a notification and the other signers are no longer asked. The reason is shown with the signer, if one was entered.
- **You cancel**: the request gets the status <Status>Canceled</Status> and the links stop working.
- **The deadline has passed**: after the day under **Sign before**, nobody can sign any more. Tillor sets the request to <Status tone="warning">Expired</Status> during the daily check. Until that check, the detail page shows that the deadline has passed. If you still want someone to sign, make a new request.

<DocScreenshot src="/screenshots/handtekeningen/signatures-detail-declined.png" alt="Declined request with the customer's reason" />

## The signed PDF [#de-ondertekende-pdf]

On the detail page, you download the PDF with **Download signed PDF**, below the history. The **Timestamp** is also there, see [Evidence and validity](/handtekeningen/bewijs-en-geldigheid#zegel-en-tijdstempel).

By email, the PDF is attached to the message to the signer. If that does not work, there is a button to download it. Someone with only a phone number receives a text message with a link.

The signed PDF and the original PDF are the evidence of the signing. You therefore cannot delete them, only archive them.

## History and events [#verloop-en-gebeurtenissen]

Under **History** is every step with time and who did it: created, sent, link sent, page opened, code sent, wrong code, signed, declined, set back, canceled, expired and completed. The same line is on the customer's **Events** tab and in the [activity log](/activiteitenlog).

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the Send reminder button">
The button is only shown for a signer with the status **Link sent**, so one whose turn it is. For a staff member it is never shown, because they sign in Tillor. If it is shown but greyed out, you are missing the **Manage signature requests** permission.
</Accordion>
<Accordion title="Tillor says: The reminder could not be sent">
Try again. If it keeps failing, check the signer's email address and phone number. For a customer or contact, you change those in their details. For an external party, cancel the request and make a new one with the right details.
</Accordion>
<Accordion title="The Back to editing button is missing">
Someone other than you has already signed. The request can then no longer go back to a draft. Cancel the request with **Cancel request** and make a new one.
</Accordion>
<Accordion title="Tillor says: The request could not be canceled">
Canceling is only possible for a request that is <Status tone="info">In progress</Status>. Reload the page and see what the status is now. You can no longer cancel a completed, declined or expired request.
</Accordion>
<Accordion title="The request is still In progress, but the deadline has passed">
You see *The signing period has ended; the request expires at the next daily check.* Nobody can sign now. As soon as the check has run, the request is <Status tone="warning">Expired</Status>.
</Accordion>
<Accordion title="I see Everyone signed, but no signed PDF yet">
Tillor is still preparing the PDF. Reload the page after a few minutes. As soon as it is ready, it is with the customer's documents and **Download signed PDF** appears. If it is still not ready after a quarter of an hour, Tillor tries again at the next daily check.
</Accordion>
<Accordion title="I cannot delete the document or the signed PDF">
That is intended. The original PDF and the signed PDF are the evidence. You can archive them.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="How someone signs" href="/handtekeningen/ondertekenen" />
  <Card title="Evidence and validity" href="/handtekeningen/bewijs-en-geldigheid" />
  <Card title="Documents" href="/documenten" />
</Cards>


# Identity scans (/en-GB/identiteitsscans)

With an identity reader, you scan passports, ID cards, driving licences, visas and residence documents. Tillor recognises the document type, reads the data and uses it to create a customer quickly, without retyping everything. The reader sends the scan to your organisation via the [Tillor connector](/connector) on your local network. How to create a customer afterwards is covered in [Creating a customer from a scan](#klant-aanmaken-vanuit-een-scan).

<Callout type="info" title="Good to know">
- Tillor automatically deletes a scan without a linked customer after 7 days, together with the associated files.
- A linked scan is kept until you unlink or delete it. You decide the retention period.
- Creating a customer from a scan requires at least a first name in the scan.
- If a customer with the same national register number already exists, link the scan to that customer instead of creating a duplicate.
- Scan files are stored encrypted. The page images carry a **Not valid as ID** watermark. The portrait stays without a watermark.
- The connector listens on port 8765 by default.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  subgraph lokaal[Lokaal netwerk]
    R[Identiteitslezer]
    C[Tillor-connector]
  end
  T[Openstaande scan in Tillor]
  K[Klant of contactpersoon]
  R --> C
  C --> T
  T -->|Klant aanmaken of koppelen| K
  T -->|Niet gekoppeld na 7 dagen| X[Automatisch verwijderd]
```

A scan starts as a pending scan. If you link it to a customer or contact, it is kept with that customer.

## Creating a customer from a scan [#klant-aanmaken-vanuit-een-scan]

Before you start:

- The scan must be in Tillor as a pending scan. If it is not there, see Problems at the bottom.
- The scan needs a first name.

<Steps>
<Step>
### Open the customer list [#open-de-klantenlijst]
Go to <UIPath>Customers > Overview</UIPath> and click **Create new customer**. As long as there are pending scans, the button shows a menu: choose **Manual** or a scan from the list.

<DocScreenshot src="/screenshots/klanten/customer-create-scan-menu.png" alt="Create new customer - menu with pending identity scan" />
</Step>
<Step>
### Check the scan [#controleer-de-scan]
After you choose a scan, a confirmation opens with a preview of the document and the data from the reading strip. Click **Create customer**.

<DocScreenshot src="/screenshots/klanten/customer-create-from-scan-confirm.png" alt="Confirmation after choosing a pending scan with document preview" />
</Step>
</Steps>

The same route works via **Start reservation** (**New customer…**) and via the panel at the bottom right with **Make customer based on scan**.

<DocScreenshot src="/screenshots/klanten/identity-scan-dock.png" alt="Panel at the bottom right - pending identity scan with document preview" />

### What happens next? [#wat-gebeurt-er-daarna]

- Tillor creates the customer, links the scan and fills in first name, last name, date of birth, address and other fields where possible.
- You land on the new customer profile.
- The scan is no longer in the queue and is kept with the customer.
- The linking appears on the customer's **Events** tab.

## Linking to an existing customer or contact [#koppelen-aan-een-bestaande-klant-of-contactpersoon]

Besides a new customer, you can also link a scan to an existing customer or contact.

<Tabs items={["To a customer", "To a contact"]}>
<Tab value="To a customer">
On the customer profile, a dotted card **Assign a pending identity scan** appears as long as there are suitable pending scans. Choose a scan with **Choose scan…** and click **Assign to this customer**.
</Tab>
<Tab value="To a contact">
On a contact's card, you can link a scan that has no contact yet and contains at least a first name, with **Assign to contact**. You can also have a new contact created with **Create contact from scan**.
</Tab>
</Tabs>

After linking, Tillor completes the customer's or contact's details where possible. As first name, Tillor only takes over the first part of the first name, for example `Andy` from `Andy Adhemar R`. On the scan, all first names stay visible.

## Unlinking, exporting or deleting a scan [#een-scan-ontkoppelen-exporteren-of-verwijderen]

A linked scan has actions for **Download**, **Export PDF**, **Unlink scan** and **Delete scan**. Deleting permanently removes the scan and all encrypted files and cannot be undone.

## Retention period and your responsibility [#bewaartermijn-en-jouw-verantwoordelijkheid]

<Callout type="warn" title="7 days for pending scans">
Tillor automatically deletes scans that are not yet linked to a customer after 7 days (the scan and the associated files). Link or process pending scans in time via **Create new customer**, the panel at the bottom right or the dotted card on a customer profile.
</Callout>

A different rule applies to linked scans: they are kept until your organisation unlinks or deletes them. You decide whether, when and on what legal basis identity documents are scanned and how long linked scans are needed. Tillor processes the scans as a processor on your instruction. Compliance with privacy legislation, retention periods for linked scans and timely deletion when storage is no longer needed are your responsibility as the controller.

## Problems? [#problemen]

<Accordions>
<Accordion title="No scan arrives in Tillor">
On the reader, check the connector's IP address and port 8765, and whether the connector is running. See [Connector](/connector).
</Accordion>
<Accordion title="The scan is not in the menu or the panel">
Only scans without a linked customer count as pending. If the scan is already linked, or older than 7 days and therefore deleted, it is no longer there.
</Accordion>
<Accordion title="Make customer based on scan is greyed out">
The reason is shown with the scan. If the scan has no first name, it says *fill that in on the scanner or link this scan manually*. If the document is still valid and a customer with this national register number already exists, open the suggested customer at the top of the card or link the scan to that customer.
</Accordion>
<Accordion title="Tillor says: Could not create customer from this scan">
The customer was not created and the scan stays pending. Try again. If that does not work, create the customer manually and link the scan with **Assign to customer**.
</Accordion>
<Accordion title="Tillor says: Could not link scan to customer">
Try again, or use the panel at the bottom right.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Identity scan**: the data and images read from one identity document.
- **Pending scan**: a scan that is not yet linked to a customer and disappears after 7 days.
- **Reading strip (MRZ)**: the lines of letters and digits at the bottom of the document that the reader reads out.
- **Connector**: the box on your local network that forwards scans to Tillor. See [connector](/begrippen#connector).
- **Customer**: the record in Tillor. See [customer](/begrippen#klant).

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" description="Creating a customer, including the route with a scan" />
  <Card title="Connector" href="/connector" description="The connector box in your park" />
  <Card title="Practical examples" href="/praktijk" />
</Cards>


# Reading and replying to conversations (/en-GB/inbox/gesprekken)

The inbox brings together all conversations from your connected channels. Here you read them, reply and tidy up. How to connect a channel is described under [Inbox](/inbox).

Before you start:

- You need the **View inbox** permission to read conversations and **Manage inbox** to reply or archive. Without **View inbox**, the inbox does not appear in the sidebar.
- At least one channel must be connected. Otherwise you see a link to <UIPath>Settings > Integrations</UIPath>.

<Requires permission="View inbox" />

## Opening the inbox [#de-inbox-openen]

<Steps>
<Step>
### Go to the inbox [#ga-naar-de-inbox]
In the sidebar, under **Support**, choose **Inbox** (marker **1** in the screenshot). If no channel is connected yet, Tillor shows a link to <UIPath>Settings > Integrations</UIPath>.
</Step>
<Step>
### Choose a conversation [#kies-een-gesprek]
On the left is the **Conversations** list with the threads from all channels. Use **Open** and **Archived** to switch between active and finished conversations. Click a conversation to open it on the right.
</Step>
</Steps>

<DocScreenshot src="/screenshots/communicatie/inbox/inbox-overview.png" alt="Inbox - conversation list with demo conversations and an empty detail column" />

An open conversation shows the messages in order, with name and time. At the bottom is the reply field (marker **2** in the example).

<DocScreenshot src="/screenshots/communicatie/inbox/inbox-conversation-whatsapp.png" alt="Inbox - WhatsApp conversation with reply field" />

The background of a conversation follows the channel: beige for WhatsApp, blue bubbles for Messenger, pink for Instagram and light grey for website chat.

## Sending a reply [#een-antwoord-sturen]

<Requires permission="Manage inbox" />

<Steps>
<Step>
### Open the conversation [#open-het-gesprek]
Click the conversation in the list.
</Step>
<Step>
### Type your reply [#typ-je-antwoord]
Type in the reply field at the bottom.
</Step>
<Step>
### Send [#verstuur]
Click **Send** or press **Ctrl+Enter**.
</Step>
</Steps>

Next to the time on your own messages you see a tick for sent, a double tick for delivered and a blue double tick for read. Replies you send through the WhatsApp Business app or the Messenger app also appear in the conversation for as long as the integration is active.

You cannot edit a message you have sent yourself. The channels do not offer that option. On Messenger and Instagram, a delete button appears next to your own text messages. It only hides the message in Tillor; the customer keeps the message in their own app.

Incoming Messenger photos are stored and shown in the conversation; in the list, a photo icon appears instead of text. Emoji reactions to Messenger messages appear as counters under the message.

### WhatsApp and the 24-hour reply window [#whatsapp-en-het-antwoordvenster-van-24-uur]

A customer who sends you a message on WhatsApp opens a free 24-hour reply window. Tillor shows **Free reply window open** with a countdown. If the window has closed, **24-hour window closed** appears and your reply is sent as a paid WhatsApp template, until the customer writes again.

- If no payment method has been added for your WhatsApp Business account in Meta WhatsApp Manager, Tillor blocks paid replies. Free replies within the window remain possible.
- If Meta has not yet approved the template in your organisation's language, your reply waits. This usually takes a few minutes and can take up to 48 hours.

## What happens next? [#wat-gebeurt-er-daarna]

- Your reply appears in the conversation with a tick: sent, delivered or read. If delivery fails, it shows **Not delivered**.
- An archived conversation disappears from **Open**. If the customer writes again, the conversation reappears.
- The conversation also appears on the customer, under <UIPath>Customers > customer > Communication</UIPath>.

## Finding and tidying up conversations [#gesprekken-terugvinden-en-opruimen]

- **Search**: filter threads by name or phone number, within **Open** or **Archived**.
- **Unread**: in **Open**, unread conversations are shown in bold with a red dot. Click **Mark all as read** at the top of the list to mark everything as read in one go.
- **Archive**: click **Archive** on a finished conversation in **Open**.
- **Restore**: open a conversation in **Archived** and click **Restore** to bring it back and be able to reply again.
- **Context menu**: right-click or long-press a conversation for **Mark as read**, **Mark as unread**, **Pin conversation** or **Unpin conversation**, **Archive** and **Restore**.

The number next to **Inbox** in the sidebar counts open conversations where the last message is from the customer and still awaits a reply. New messages appear live; the number updates itself.

## Tags [#tags]

With tags you label conversations for your whole team.

1. Open a conversation and use the **Tags** block in the side panel.
2. Create a tag with **New tag** or choose an existing one. Use the tag menu to edit or delete tags.
3. Filter the list with the tag icon next to the platform filter.

Tags with **AI can apply** can be added by Tillie after an automatic reply. Tags your team has already set stay in place.

## Notifications [#meldingen]

Users with **Inbox message notifications** receive a push notification for every new message from a customer. Your own replies do not trigger a notification.

With **View inbox** you also see a notification at the bottom right for a new message, in the same dock as pending identity scans and active phone calls. It shows the sender, the channel and a snippet of the text. Click it to open the conversation. The notification disappears after about ten seconds, unless you keep the mouse over it. If the conversation is already open, no notification appears.

## Conversations and customers [#gesprekken-en-klanten]

Tillor links a conversation to a customer where possible:

- WhatsApp by phone number.
- Messenger by a matching name, or by a phone number or email address that the customer shares in the conversation themselves.
- Instagram by a matching name or `@` username.

Meta does not pass on an email address or phone number through Messenger and Instagram. A customer's open conversations also appear under <UIPath>Customers > customer > Communication</UIPath>.

The side panel on the right shows the participant's details per channel, such as the WhatsApp number, the Instagram username with profile link or the page for website chat. Use the panel icon above the conversation to hide or show the panel.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the Inbox in the sidebar">
You need the **View inbox** permission. Ask an administrator to grant it under <UIPath>Settings > Users</UIPath>, with **Edit permissions** next to your name.
</Accordion>
<Accordion title="I cannot send a reply">
To reply you need **Manage inbox**. You also cannot reply in an archived conversation: click **Restore** first.
</Accordion>
<Accordion title="Tillor reports Failed to send message">
Check that the conversation is open and that you have **Manage inbox**. On WhatsApp, the closed reply window can also be the cause, see above. Then try again.
</Accordion>
<Accordion title="My message shows Not delivered">
The channel could not deliver the message. On WhatsApp this is usually down to the closed 24-hour window or a missing payment method at Meta.
</Accordion>
<Accordion title="The inbox is empty">
No channel has been connected yet, or no messages have come in yet. Connect a channel under <UIPath>Settings > Integrations</UIPath>.
</Accordion>
<Accordion title="A customer edited or deleted a message">
Tillor updates the conversation automatically when a customer edits or withdraws a message on Messenger or Instagram, or edits one on WhatsApp (within 15 minutes).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Overview" href="/inbox" description="Channels and permissions" />
  <Card title="Conversations via website chat" href="/inbox/website-chat-gesprekken" description="Extras for the chat on your site" />
  <Card title="Inbox AI assistant" href="/inbox/inbox-ai-assistant" description="Tillie on all channels" />
</Cards>


# Inbox AI assistant (Tillie) (/en-GB/inbox/inbox-ai-assistant)

**Tillie** is the default name of the AI assistant in the [Tillor inbox](/inbox). She answers frequently asked questions, collects details for reservation or sales enquiries and hands the conversation over to your team when a colleague is needed. Tillie works on **all inbox channels**: [website chat](/inbox/website-chat), [WhatsApp Business](/inbox/whatsapp-business-inbox), [Messenger](/inbox/messenger) and [Instagram Direct](/inbox/instagram).

<Callout type="info" title="Separate from website chat">
Install **Inbox AI assistant** separately under **Settings > Integrations**. The assistant belongs to the inbox, not only to the website widget.
</Callout>

## Installing the integration [#integratie-installeren]

1. Go to **Settings > Integrations** (sidebar, under **Support**)
2. Open **Inbox AI assistant** in the list
3. Click **Install**
4. Under **Settings**, set what Tillie may do (see the fields below)

| Field | What does it do? |
|------|----------------|
| **Inbox AI enabled** | Main switch for all Inbox AI features. Turn it off to stop without uninstalling |
| **Send automatic replies** | When off: Tillie sends no messages to visitors. Translations, language detection and draft replies for the team can stay on separately |
| **Automatically enable AI for new threads** | Only applies when automatic replies are on. When off: every new conversation starts without AI; you enable AI per conversation in the sidebar. When on: new inbox conversations on all channels get AI straight away (with a 30-minute pause after a team message) |
| **Generate staff draft replies** | Lets colleagues generate an AI draft in the compose box. That draft is never sent automatically |
| **Translate messages** | Translates incoming messages into the organisation language and team replies into the contact's language. Team replies also get tidy punctuation, capital letters and chat abbreviations written out in full (even when no translation is needed) |
| **Detect contact language** | Uses AI to recognise the visitor's language when it is not yet known, and stores it on the conversation |
| **AI assistant name** | Name used in replies and prompts (default **Tillie**) |
| **MCP servers (JSON)** | Optional. Read-only MCP connections (URL and headers) |
| **MCP tools** | After saving: **Load tools**, list the read-only tools and switch each tool on or off |

<Callout type="info" title="Translate only, no automatic replies">
Turn **Inbox AI enabled** on, **Translate messages** (and optionally **Detect contact language**) on, and **Send automatic replies** off. Tillie then translates, but sends nothing to visitors.
</Callout>

### MCP tools (optional) [#mcp-tools-optioneel]

If your park has an MCP server with read-only connections, Tillor can fetch **live park data** during a conversation. Think of activities, caravans for sale, or other data your server offers.

Tillor has **no fixed list of tool names**. Which tools exist, you see after **Load tools** in the integration settings. You can only enable tools that your MCP server marks as read-only.

1. Fill in **MCP servers (JSON)** (URL and headers).
2. Save and click **Load tools**.
3. Enable the tools that suit your park.

Depending on the AI configuration of your environment, Tillie chooses for herself which enabled tool fits, based on your server's tool description. She never calls tools you have not enabled.

Results from MCP end up in Tillie's reply. They do not replace the knowledge base: she still does not make up prices, availability or rules if they come from nowhere.

<Callout type="info" title="No reply from Tillie?">
Tillie uses an AI model that Tillor sets up for your environment. If the assistant does not reply, contact Tillor support.
</Callout>

## What Tillie does after a visitor message [#wat-tillie-doet-na-een-bezoekersbericht]

After every new incoming message in a conversation where AI is active:

1. Tillor shows a **typing indicator** on the channel while the reply is being generated
2. Tillor determines the intent: **reservation**, **sales** or **other** (organisations with a rental caravan flow also **rental caravan**)
3. Tillie replies in the visitor's language; the typing indicator then disappears

Tillie decides for herself, based on her instructions, when to reply and when to stay silent. To an opening greeting ("hi", "hey", "hello") she replies with a short welcome and the question of what she can help with. After a closing thank-you, she does not respond again to a short "thanks", "ok" or "no" from the visitor, so no thank-you loop arises.

| Intent | Behaviour |
|-----------|--------|
| **Reservation** | Asks for missing details: arrival, departure, type (tent, mobile home, touring caravan), dogs yes/no (and how many), number of people, children and ages, then name, email and phone number, and optionally the number plate for check-in (can be skipped). Details Tillor already knows (e.g. from the website widget or WhatsApp) are filled in; only missing fields are asked. For a weekday ("Monday"), Tillie first asks a confirmation question ("Do you mean …?") before continuing. Every reply ends with one question. Answers short policy questions from the knowledge base (e.g. changing a reservation later) and then carries on collecting. Once everything is complete, Tillie summarises the **enquiry** and hands the conversation over to a colleague - there is no final reservation yet |
| **Rental caravan** | Collects name, email, address, country and reason for stay (on request), then hands over to your team |
| **Sales** | Explains that the visitor has to come by the office for a viewing or purchase, and passes it on to your team |
| **Other** | Only replies if the answer is in the knowledge base. Otherwise Tillie honestly says she does not know, offers to pass the question on to a colleague, and hands the conversation over |

Tillie **does not make up prices, availability or rules**. Only what is in the knowledge base may be stated as fact.

### Booking form on your website [#boekingsformulier-op-je-website]

Do you connect your own form to [Website chat](/inbox/website-chat)? Then you can have Tillie only confirm and hand over straight away, without intake questions. That suits a form whose tab closes afterwards. See [Website chat API - metadata](/ontwikkelaars/website-chat#metadata-boekingsformulier).

## Per conversation: Automatic, On or Off [#per-gesprek-automatisch-aan-of-uit]

In the conversation details in the sidebar you choose per thread:

| Mode | Behaviour |
|-------|--------|
| **Automatic** | Tillie replies, but pauses for **30 minutes** after every message from your team |
| **On** | Tillie always replies, even straight after a team message |
| **Off** | Tillie does not reply to this conversation |

During the pause you see a countdown in the sidebar.

## Tags after an AI reply [#tags-na-een-ai-antwoord]

In the side panel you can create and assign organisation-wide **tags** (permission **Manage inbox**). Use **New tag** to create a tag. Open the tag menu on a conversation to assign tags; editing and deleting each tag are in that same menu. Tick **AI can apply** if Tillie may add that tag after an automatic reply. Tillie then chooses zero or more of those tags herself based on the conversation; tags your team has already set stay in place.

Typical tags are, for example, **Sales**, **Booking** and **Urgent**. Tillie recognises those names and links them to what she has already established in the conversation:

| Tillie intent | Matches tag names such as |
|---|---|
| Sales | Verkoop, Sale |
| Reservation | Boeking, Reservatie, Booking |
| Rental caravan | Caravan, Verhuur |
| Urgent hand-over | Urgent, Spoed, Dringend |

The tag name does not have to match exactly: **Boeking aanvragen** also counts as a booking tag. Only tags with **AI can apply** are eligible.

## Language, tone and contact details [#taal-toon-en-contactgegevens]

Replies follow the visitor's language - not only the four widget languages (`en`, `nl`, `de`, `fr`), but any language Tillie can reply in (e.g. Spanish, Polish, Turkish). If someone explicitly asks for another language, Tillie switches and stores the chosen language on the conversation.

**Hand-over summaries** (visible to your team only) always follow the **organisation language** from Tillor, for every hand-over (reservation, rental caravan, sales, open question, explicit request for a colleague), regardless of the language of the conversation. Tillie receives that organisation language in every prompt.

Messages to visitors (AI and team) are always **plain text**, not markdown, because WhatsApp, Instagram, Messenger and the widget do not support it. On WhatsApp, Tillie may add up to three reply buttons under a short reply, when a tap is a choice the message itself already mentions. The message stays readable if the customer types instead of tapping. Outside the 24-hour window, the reply is sent as a template without buttons.

Tillie stays calm and professional, does not talk about competitors, and does not ignore safety rules if a visitor asks her to ignore instructions. Contact details for referrals come from your **Tillor organisation profile** (name, address, phone, email, website). You set **office opening hours** under **Settings > Opening hours** (weekly hours, seasonal periods, public holidays and exceptions); Tillie uses those hours to say when a colleague can reply. Keep those fields up to date. About a week before a public holiday, Tillor reminds the support address by email if the hours for that day have not been filled in yet.

## Events in the conversation (for your team only) [#gebeurtenissen-in-het-gesprek-alleen-voor-je-team]

During reservation intake, Tillie updates name, email and phone as soon as the visitor gives them. In the inbox, an **AI assistant updated participant details** event (from → to) then appears, visible to your team only.

On hand-over, an **AI assistant handed this conversation to your team** event appears: a prominent card with a summary (table for reservation or rental caravan details, plus notes for open questions). The summary is always in the **language of your organisation** (nl, en, de or fr), even when the visitor chats in another language. The visitor does not see that card.

<DocScreenshot src="/screenshots/communicatie/inbox/inbox-conversation-website.png" alt="Inbox - website chat with AI hand-over and conversation details" />

## Knowledge base: facts Tillie may use [#kennisbank-feiten-die-tillie-mag-gebruiken]

Tillie answers questions based on a **knowledge base**: short articles with verified facts about your park, for example opening hours, pet rules, the swimming pool, charging points or how to change a reservation later.

Some articles apply to all Tillor organisations, others are specific to your park. In a conversation, Tillie only uses the general articles plus the articles added for your organisation.

Do you want topics added, changed or removed? Let Tillor support know. We fill and maintain the knowledge base together with you, tailored to what your reception wants to be able to answer.

## Conversation flows: a script per intent [#gespreksflows-draaiboek-per-bedoeling]

Besides the knowledge base, Tillie follows **conversation flows**: agreements on which details she asks for, in which order, and when she hands the conversation over to your team. Every intent (reservation, rental caravan, sales, other - see the table above) has such a flow.

The flows are set up by default, but Tillor tunes them with you to your park. Would you like different details to be asked for a reservation enquiry, for example, or Tillie to hand over sooner? Let Tillor support know.

<Callout type="warn" title="First version">
Check AI replies in the inbox before you trust them to visitors. A reservation via chat remains an **enquiry** - not a final booking.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- A conversation that Tillie hands over appears in the inbox with a block **Tillie handed this conversation to your team** and the collected details.
- Your team receives a notification. For an urgent hand-over this goes through the **Urgent AI handoff** notification. See [Notification types](/communicatie/notificatietypes).
- If a colleague replies, Tillie pauses for 30 minutes in the **Automatic** mode.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillie does not reply">
Check that **Inbox AI enabled** and **Send automatic replies** are on under <UIPath>Settings > Integrations > Inbox AI assistant</UIPath>. Then check in the conversation's sidebar whether the mode is not set to **Off**, or whether a countdown is running after a message from your team.
</Accordion>
<Accordion title="New conversations start without Tillie">
**Automatically enable AI for new threads** is off. Turn the switch on, or choose **On** per conversation.
</Accordion>
<Accordion title="Tillie says she does not know something">
Tillie only uses what is in the knowledge base and does not make up prices, availability or rules. Add to the knowledge base.
</Accordion>
</Accordions>

## Related [#gerelateerd]

<Cards>
  <Card title="Inbox" href="/inbox" description="Reading and replying to conversations" />
  <Card title="Website chat" href="/inbox/website-chat" description="Live chat on your own website" />
  <Card title="WhatsApp Business" href="/inbox/whatsapp-business-inbox" description="WhatsApp in the inbox" />
  <Card title="Messenger" href="/inbox/messenger" description="Connect Facebook Messenger" />
  <Card title="Instagram" href="/inbox/instagram" description="Connect Instagram Direct" />
</Cards>


# Overview (/en-GB/inbox)

In the inbox you read and reply to messages from customers and visitors that come in through WhatsApp, Messenger, Instagram or the chat on your website, all in one place. You find it in the sidebar under **Support > Inbox**. First you connect the channels you want to use, then you work in [Reading and replying to conversations](/inbox/gesprekken) every day.

<Callout type="info" title="Not for automatic notifications">
The inbox is meant for two-way traffic with customers. Automatic WhatsApp notifications, for example for a low NFC balance, go through Twilio and not through these integrations.
</Callout>

<Callout type="info" title="Good to know">
- A new message appears as a card at the bottom right and disappears after about ten seconds. The number next to **Inbox** counts open conversations waiting for a reply
- The AI assistant Tillie pauses for 30 minutes after a colleague has replied
- A chat message on the website can contain a maximum of 4096 characters, without images or files
- A customer can edit a WhatsApp message up to 15 minutes after sending it, and you see that in the conversation
- The email reminder to a website visitor goes out after about 5 minutes of inactivity. The link works for 30 days
- A message of your own that you delete in Tillor (Messenger and Instagram) only disappears in Tillor, not for the customer

</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

You install each channel separately. All conversations then end up in the same list, and Tillor links them to a customer where possible.

```mermaid
flowchart LR
  W[WhatsApp] --> I[Inbox]
  M[Messenger] --> I
  G[Instagram] --> I
  C[Chat on your website] --> I
  I --> K[Linked customer via phone number or name]
  I --> A[Tillie replies or hands over]
  A --> T[Your team]
  I --> T
  T -->|reply| W
  T -->|reply| M
  T -->|reply| G
  T -->|reply| C
```

- Your team replies in Tillor. The reply goes back to the customer through the same channel.
- Tillie, the AI assistant, can reply and hand a conversation over to your team. You decide that per conversation.
- Replies you send outside Tillor, for example in the WhatsApp Business app, also appear in the conversation.

## Connecting channels [#kanalen-koppelen]

Install an integration per channel under <UIPath>Settings > Integrations</UIPath>.

<Cards>
  <Card title="Website chat" href="/inbox/website-chat" description="Chat button on your own site, without an external account" />
  <Card title="WhatsApp Business" href="/inbox/whatsapp-business-inbox" description="Connect a WhatsApp number via Meta" />
  <Card title="Messenger" href="/inbox/messenger" description="Connect a Facebook page via Meta" />
  <Card title="Instagram" href="/inbox/instagram" description="Connect Instagram Direct via Meta" />
  <Card title="Inbox AI assistant" href="/inbox/inbox-ai-assistant" description="Tillie replies and hands over on all channels" />
</Cards>

When you connect Messenger, Tillor imports the page's existing conversations. If Messenger is already connected, you can also start that synchronisation manually from the inbox.

## Working day to day [#dagelijks-werken]

<Cards>
  <Card title="Reading and replying to conversations" href="/inbox/gesprekken" description="Replying, archiving, tags and notifications" />
  <Card title="Conversations via website chat" href="/inbox/website-chat-gesprekken" description="What you see for a website visitor" />
</Cards>

## Permissions [#rechten]

| Permission | What may the user do? |
|-----------|------------------------|
| **View inbox** | Open the inbox and read conversations |
| **Manage inbox** | Send replies, archive, restore and pin conversations, mark as unread and delete your own messages in Tillor (Messenger and Instagram) |
| **Inbox message notifications** | Receive push notifications for new messages from customers |

Set permissions under <UIPath>Settings > Users</UIPath>.

## Terms [#begrippen]

- **Conversation or thread**: all messages with one customer or visitor on one channel.
- **Open and Archived**: the two tabs of the conversation list. Archiving takes a conversation out of **Open**, restoring puts it back.
- **Tillie**: the default name of the AI assistant in the inbox. You can change the name.


More terms are in the [glossary](/begrippen).


# Instagram (/en-GB/inbox/instagram)

With **Instagram** you receive Instagram Direct messages in the [Tillor inbox](/inbox). The integration uses a linked **Facebook Page** with an **Instagram Professional account** in Meta Business Suite.

Before you start:

- You need the **Manage integrations** permission.
- Your Instagram account is a Professional account (Business or Creator), linked to a Facebook Page.

## Installing the integration [#integratie-installeren]

1. Go to **Settings** (sidebar, under **Support**)

<DocScreenshot src="/screenshots/communicatie/providers/instagram/marketplace-nav.png" alt="Navigation to Settings" />

2. Choose **Integrations** and open **Instagram** in the list (marker **2**)

<DocScreenshot src="/screenshots/communicatie/providers/instagram/marketplace-instagram.png" alt="Settings > Integrations - Instagram in the list" />

3. Click **Install** (marker **1**) and complete the Meta OAuth flow (Instagram messaging permissions)

<DocScreenshot src="/screenshots/communicatie/providers/instagram/instagram-install.png" alt="Instagram detail - Install" />

4. Choose the **Facebook Page** that is linked to your Instagram Professional account
5. Check the **Instagram username** field under the page selection (Tillor shows the linked account, for example `@uwaccount`)
6. Save the settings

Without a linked Instagram Professional account on the selected page, Tillor cannot complete the integration.

## What happens next? [#wat-gebeurt-er-daarna]

- After installation, incoming Instagram Direct messages arrive in the [inbox](/inbox) automatically.
- Replies sent through the Instagram app also appear in the inbox. Messages you send through Tillor are not shown twice.
- If no messages come in after all, contact Tillor support. The Instagram connection with Meta must be set up for the whole platform.
- Messenger and Instagram are separate integrations. If you want both channels in the inbox, install both.

## Problems? [#problemen]

### Connecting failed or no Instagram on the page [#koppelen-mislukt-of-geen-instagram-op-de-pagina]

If installation stops with *The app could not be linked* or *No Instagram Professional account*, check in Meta:

1. **Instagram Professional** - your Instagram account must be Business or Creator (not a personal account).
2. **Link the page** - in [Meta Business Suite](https://business.facebook.com/) or Business Settings: link the Instagram account to the **Facebook Page** you log in with.
3. **Message access** - in the Instagram app: **Settings** > **Messages and story replies** > **Connected tools** > allow access to messages (required for Direct in inbox apps).
4. **Correct Meta login** - use an account that is an **admin** of the Facebook Page with messaging permissions.


During installation, Tillor looks up all Facebook Pages on your account and picks the first page with a linked Instagram Professional account. If you have several pages, you can choose a different page in the integration settings after installation.

<Callout type="info" title="For the technical reader">
During installation, Tillor always requests the permissions `instagram_basic`, `instagram_manage_messages` and `pages_read_engagement`. Set them to **Ready for testing** first under **Use cases** (Messenger/Instagram) in the Meta Developer Console. **Invalid Scopes** means they are not yet on the Meta app. The `instagram_business_*` permissions belong to a different login method and are not for Tillor.
</Callout>

## Related [#gerelateerd]

<Cards>
  <Card title="Inbox" href="/inbox" description="Reading and replying to conversations" />
  <Card
    title="Messenger"
    href="/inbox/messenger"
    description="Connect Facebook Messenger for the inbox"
  />
  <Card
    title="WhatsApp Business"
    href="/inbox/whatsapp-business-inbox"
    description="Connect a WhatsApp number for the inbox"
  />
</Cards>


# Messenger (/en-GB/inbox/messenger)

With **Messenger** you receive messages from customers through a linked Facebook Page in the [Tillor inbox](/inbox).

Before you start:

- You need the **Manage integrations** permission.
- You sign in to Meta with an account that is an admin of the Facebook Page.

## Installing the integration [#integratie-installeren]

1. Go to **Settings** (sidebar, under **Support**)

<DocScreenshot src="/screenshots/communicatie/providers/messenger/marketplace-nav.png" alt="Navigation to Settings" />

2. Choose **Integrations** and open **Messenger** in the list (marker **2**)

<DocScreenshot src="/screenshots/communicatie/providers/messenger/marketplace-messenger.png" alt="Settings > Integrations - Messenger in the list" />

3. Click **Install** (marker **1**) and complete the Meta OAuth flow

<DocScreenshot src="/screenshots/communicatie/providers/messenger/messenger-install.png" alt="Messenger detail - Install" />

4. On the detail page, choose which **Facebook Page** receives Messenger messages
5. Save the settings

Tillor shows the linked page under **Settings** on the detail page. After installation, Tillor receives incoming Messenger messages automatically. Replies you also send through the Messenger app appear in the inbox. Messages you send through Tillor are not shown twice.

For **Instagram Direct**, install the separate [Instagram](/inbox/instagram) integration.

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor imports the page's existing conversations. You can also start that synchronisation yourself later from the inbox.
- New messages arrive in the [inbox](/inbox) automatically. Tillor links them to a customer with the same name, or by a phone number or email address that the customer shares in the conversation.

## Problems? [#problemen]

<Accordions>
<Accordion title="No messages are coming in">
Check under <UIPath>Settings > Integrations > Messenger</UIPath> that the correct **Facebook Page** has been chosen and that the settings have been saved.
</Accordion>
<Accordion title="A conversation is not linked to a customer">
Meta does not pass on an email address or phone number through Messenger. Tillor only links on a matching name or on details the customer shares themselves.
</Accordion>
</Accordions>

## Related [#gerelateerd]

<Cards>
  <Card title="Inbox" href="/inbox" description="Reading and replying to conversations" />
  <Card
    title="Instagram"
    href="/inbox/instagram"
    description="Connect Instagram Direct for the inbox"
  />
  <Card
    title="WhatsApp Business"
    href="/inbox/whatsapp-business-inbox"
    description="Connect a WhatsApp number for the inbox"
  />
</Cards>


# Conversations via website chat (/en-GB/inbox/website-chat-gesprekken)

A conversation appears in the inbox as soon as the visitor sends their first message, with the channel **Website chat**. How to respond is described in [Reading and replying to conversations](/inbox/gesprekken). This page explains what extra you see with website chat.

<DocScreenshot src="/screenshots/communicatie/inbox/inbox-conversation-website.png" alt="Inbox - website chat with conversation details" />

In the side panel on the right is an **Open on website** button with the page where the visitor was last active, plus visitor and session details. Extra fields from the visitor form are shown there too.

## Who is the visitor? [#wie-is-de-bezoeker]

- Tillor recognises a visitor by their browser. The same browser on the same device therefore opens the same conversation.
- Name, email and phone from the visitor form are kept in that browser after the first message. If the visitor comes back later, they do not have to fill anything in again.
- If that storage is empty, for example in a different browser or after clearing, the widget fills in the details from the existing conversation.
- Messages are text of up to 4096 characters. Images and files are not supported.

## Typing and presence [#typen-en-aanwezigheid]

| What | Who sees it | Where |
|-----|--------------|------|
| **Typing…** while the visitor is writing | Your team | Below the conversation in the inbox, even before the first message |
| **Typing…** while a colleague is writing | The visitor | In the widget |
| **Online** (green dot) or **Last seen** with a time | Your team | Above the conversation |

The visitor counts as online as long as the tab is visible. The widget sends a sign of life about every 20 seconds. Fetching messages, typing and reading also count as activity.

## Ticks [#vinkjes]

Visitors see ticks next to their own messages:

| Ticks | Meaning |
|---------|-----------|
| One | Sent |
| Two grey | Your team has opened the conversation and loaded the messages |
| Two blue | Your team has marked the conversation as read |

In the inbox you see ticks next to your own replies:

| Ticks | Meaning |
|---------|-----------|
| One | Sent |
| Two grey | The visitor is on the page and has fetched the messages, even with the chat closed |
| Two blue | The visitor has the chat window open |

Replies from the inbox appear in the widget automatically, even if the visitor opens the window later.

## Visitor activity in the conversation [#bezoekersactiviteit-in-het-gesprek]

After the first message, your team sees grey info text in the conversation. The visitor does not see it. These lines do not raise an unread counter and do not trigger a push notification.

| Event | Text in the inbox |
|-------------|-------------------|
| Chat closed | User closed the chat |
| Other tab or window minimised | User switched tab or minimized the browser |
| Another page opened | User navigated to the page URL |

Navigation is also detected on sites that switch pages internally without reloading. The widget passes on the current page about every 20 seconds, so the side panel shows the last active page.

## Tillie on website chat [#tillie-op-website-chat]

Tillie, the AI assistant, also works in the widget. To use it, install **Inbox AI assistant** separately. Installation, knowledge base and behaviour are described on [Inbox AI assistant (Tillie)](/inbox/inbox-ai-assistant). Messages from Tillie get a little robot in the widget instead of the organisation logo.

<Callout type="info" title="The first message">
As soon as the visitor types, your team may see **Typing…**. The first message is only sent when they click **Send**, together with the contact details they entered.
</Callout>

## See also [#zie-ook]

<Cards>
  <Card title="Reading and replying to conversations" href="/inbox/gesprekken" description="Replying, archiving, tags" />
  <Card title="Website chat settings" href="/inbox/website-chat-instellingen" description="Widget and visitor form" />
  <Card title="Website chat API" href="/ontwikkelaars/website-chat" description="Build your own chat UI" />
</Cards>


# Website chat settings (/en-GB/inbox/website-chat-instellingen)

You find the settings under <UIPath>Settings > Integrations > Website chat</UIPath>. Installing and placing the snippet are described in [Putting the chat on your website](/inbox/website-chat).

## Widget [#widget]

| Field | What does it do? |
|------|---------------|
| **Widget enabled** | Hides the chat everywhere without removing the integration. On by default |
| **Show on Tillor public pages** | Shows the chat button on public Tillor pages such as the access pass, outstanding invoice and public map. Your own site uses the snippet. On by default |
| **Welcome message** | Text in the chat header and before the visitor's first message. Maximum 500 characters. Leaving it empty gives a default text in the widget's language |
| **Launcher tooltip** | Label for the floating button, meant for screen readers. Maximum 80 characters |
| **Reply soon message** | Line under the organisation name in the chat header, for example "We usually reply quickly" |
| **Launcher icon** | Icon on the chat button: **Speech bubble**, **Rounded chat**, **Question mark**, **Search** or **Person** |
| **Accent color** | Colour of the chat button and of the visitor's messages. Choose a colour or enter a hex value, for example `#2563eb` |
| **Allowed domains** | Comma-separated hostnames that may load the chat. Empty means: any domain |
| **Email visitors about unread replies** | See [below](#herinnering-per-e-mail). On by default |

The chat header automatically shows your organisation's logo. Messages from the AI assistant get a little robot instead of that logo. Neither can be set under Website chat.

<Callout type="info" title="Which language does the visitor get?">
If you do not set a **Welcome message**, **Launcher tooltip** or **Reply soon message**, the widget uses a default text in its own language. You set that language on the snippet with `data-locale` (see [Options on the snippet](#opties-op-het-snippet)).
</Callout>

## Visitor form [#bezoekersformulier]

Here you decide what a visitor fills in before the first message. If there are required fields, they appear together with the message field on one screen. The visitor fills everything in and clicks **Send**, with no separate intermediate step.

### Standard fields [#standaardvelden]

| Field | What does it do? |
|------|---------------|
| **Name required** | Visitors enter their name. The name is stored with the conversation |
| **Email required** | Visitors enter their email address. The address is stored with the conversation |
| **Phone required** | Visitors enter a phone number. Tillor converts it to a fixed format and uses it to link the conversation to calls and customers |

Each field is switched on or off separately. If only phone is on, the visitor only sees the phone field.

### Extra fields [#extra-velden]

Click **Add field** for your own questions. You can add a maximum of 8 extra fields. Delete a field with **Remove field**.

| Option | Explanation |
|-------|--------|
| **Field label** | What the visitor sees in the widget. Maximum 80 characters |
| **Field key** | Internal name of the field. Start with a lowercase letter and use only lowercase letters, digits and `_` (maximum 32 characters) |
| **Field type** | **Text** or **Email** |
| **Required** | The visitor must fill in the field before they can chat. A new field is required by default |
| **Placeholder** | Hint in the input field. Maximum 120 characters |

The answers to extra fields appear in the inbox with the conversation, next to the channel and visitor ID.

## Email reminder [#herinnering-per-e-mail]

Visitors often close the page before your team or Tillie replies. With **Email visitors about unread replies**, the visitor receives an email with the **Continue the conversation** button as soon as a reply is waiting that they have not read.

- The visitor must have provided an email address, via the visitor form or pre-filled. Without an address, nothing happens.
- The email only goes out once the visitor has been inactive for about 5 minutes. They receive one email per series of unread replies.
- The button opens the chat and continues the conversation, also on another device or in another browser. The link works for 30 days.
- The visitor can also reply directly to the email. That reply appears in the same conversation in the inbox, with a small envelope icon next to the message.
- Replies from Tillie count, just like replies from your team.

## Options on the snippet [#opties-op-het-snippet]

Besides `data-org-id` and `data-widget-key`, you can put optional attributes on the script. This is intended for whoever places the snippet on the site.

| Attribute | What does it do? |
|-----------|---------------|
| `data-locale` | Widget language: `en`, `nl`, `de`, `fr`, `pt` or `ro`, optionally with a region such as `nl-BE`. Default `en`; another language falls back to English. The region determines the date and time format |
| `data-accent-color` | Accent colour for this page as a 6-digit hex. Overrides the colour under **Settings** |
| `data-messages` | JSON object to adjust individual texts, for example `{"send":"Versturen","messagePlaceholder":"Typ uw bericht…"}` |
| `data-sounds` | `false` turns off sounds for new team replies and on sending. On by default |
| `data-launcher` | `false` hides the floating chat button. You then open the chat with your own button via [the widget SDK](/ontwikkelaars/website-chat#widget-sdk) |
| `data-visitor` | JSON object to pre-fill name, email and phone, for example `{"name":"Jan","email":"jan@voorbeeld.nl","phone":"+32470123456"}` |
| `data-visitor-name`, `data-visitor-email`, `data-visitor-phone` | Pre-fills one of those fields |
| `data-debug` | `true` shows log lines in the browser console |

Attributes only fill in empty fields. If the visitor has already entered details in this browser, those stay in place.

An example with Dutch texts:

```html
<script
  src="https://tillor.eu/inbox-widget.js"
  data-org-id="org_abc123"
  data-widget-key="iwk_xxx"
  data-locale="nl"
  async
  defer
></script>
```

You can also turn on debug without changing the snippet: run `localStorage.setItem('tillor-inbox-debug', '1')` in the browser console and refresh the page.

## Spam protection [#spambeveiliging]

The widget does not use a captcha. Tillor protects sending with the widget key and with **Allowed domains**. If your contact form has its own captcha, it may stay as an extra layer.

## Terms for visitors [#voorwaarden-voor-bezoekers]

Under the message field is a short notice that by sending, the visitor agrees to the [website chat terms](https://tillor.eu/chat-terms). The link opens in a new tab and follows the language of `data-locale`.

## See also [#zie-ook]

<Cards>
  <Card title="Putting the chat on your website" href="/inbox/website-chat" description="Installing and placing the snippet" />
  <Card title="Conversations via website chat" href="/inbox/website-chat-gesprekken" description="What you and the visitor see" />
  <Card title="Website chat API" href="/ontwikkelaars/website-chat" description="Widget SDK and your own chat UI" />
</Cards>


# Putting the chat on your website (/en-GB/inbox/website-chat)

With the Website chat integration, your site gets a chat button. Messages from visitors end up in the [inbox](/inbox), alongside WhatsApp, Messenger and Instagram.

<Requires permission="Manage integrations" />

<Steps>
<Step>
### Install the integration [#installeer-de-integratie]
Go to <UIPath>Settings > Integrations</UIPath> and open **Website chat**. Click **Install**. No link to an external account is needed; Tillor creates the widget key itself.
</Step>
<Step>
### Set up the widget [#stel-de-widget-in]
Under **Settings** on the same page, fill in at least the **Welcome message** and the **Accent color**. Also fill in **Allowed domains** so that only your site may load the chat. All options are described on [Website chat settings](/inbox/website-chat-instellingen).
</Step>
<Step>
### Copy the snippet [#kopieer-het-snippet]
Under **Embed on your website**, click **Copy snippet**. If the block is not there, save the settings and refresh the page.
</Step>
<Step>
### Paste the snippet on your site [#plak-het-snippet-op-je-site]
Paste the snippet before the closing `</body>` tag on every page where the chat button should appear. For a site with a shared template or footer, place it once in that template.
</Step>
</Steps>

## What do you see afterwards? [#wat-zie-je-daarna]

Open your site. A chat button appears at the bottom right. Send a test message yourself: the conversation appears in the inbox with the channel **Website chat**. An explanation of what you and the visitor see is on [Conversations via website chat](/inbox/website-chat-gesprekken).

<Callout type="info" title="The widget key is public">
The key is readable in the snippet, as with other chat products. Limit misuse with **Allowed domains** (comma-separated hostnames, for example `recreatiepark-het-meer.be, www.recreatiepark-het-meer.be`). If you leave the field empty, the chat works on every domain where the snippet is placed.
</Callout>

## Chat on public Tillor pages [#chat-op-publieke-tillor-paginas]

If **Website chat** is installed, **Widget enabled** is on and **Show on Tillor public pages** is on, the chat button also appears on your organisation's public pages. You do not need to place a snippet there. This covers, among others, the pages for an access pass, an outstanding invoice, an NFC tag, the organisation details and the public map.

- On those pages, Tillor uses the **Accent color** from the settings.
- **Allowed domains** only applies to your own website, not to the Tillor pages.
- If you turn **Widget enabled** off, the button disappears everywhere. If you only turn **Show on Tillor public pages** off, the chat keeps working on your own site.

## Turning the chat off temporarily [#de-chat-tijdelijk-uitzetten]

Turn **Widget enabled** off under <UIPath>Settings > Integrations > Website chat</UIPath>. The integration stays installed and your widget key does not change. Turn the switch back on to bring the chat back.

## Problems? [#problemen]

<Accordions>
<Accordion title="The chat button does not appear on my site">
First check that **Widget enabled** is on. If there is a list under **Allowed domains**, check that the page's hostname is in it, including `www.` if your site works with it. Also check that the snippet is really on that page and not only in a template that page does not use.
</Accordion>
<Accordion title="The embed snippet does not load in the settings">
Tillor then shows a message that the snippet could not be loaded. Save the settings and refresh the page.
</Accordion>
<Accordion title="The chat is on Tillor pages, but not on my site">
No snippet is needed on Tillor pages. Your own site only shows the chat with the snippet from step 3.
</Accordion>
<Accordion title="I want to connect my own contact form or replace the button">
A developer handles that with the widget SDK. See [Website chat API](/ontwikkelaars/website-chat).
</Accordion>
<Accordion title="A visitor sees You sent a lot of messages in a short time">
Tillor limits how much a visitor sends through the chat, so a script cannot flood your inbox and Tillie's replies: 10 messages per minute and 200 per day per visitor, and 30 per minute and 600 per day for everyone on the same network together (such as your campsite's wifi). Attachments: 10 per hour per visitor and 50 per hour per network. After a minute the visitor can carry on; no message that was already sent is lost.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Website chat settings" href="/inbox/website-chat-instellingen" description="All fields and embed options" />
  <Card title="Conversations via website chat" href="/inbox/website-chat-gesprekken" description="What you and the visitor see" />
  <Card title="Website chat API" href="/ontwikkelaars/website-chat" description="Connect your own form or chat UI" />
  <Card title="Inbox AI assistant" href="/inbox/inbox-ai-assistant" description="Let Tillie reply" />
</Cards>


# WhatsApp Business (/en-GB/inbox/whatsapp-business-inbox)

With **WhatsApp Business** you receive and reply to customer messages via WhatsApp in the [Tillor inbox](/inbox). This is **not** the same as WhatsApp notifications via Twilio.

<Callout type="info">
For automatic WhatsApp messages (notifications), see [Twilio](/communicatie/providers/twilio). The marketplace app **WhatsApp Business** is only for inbox conversations.
</Callout>

Before you start:

- You need the **Manage integrations** permission.
- You have a WhatsApp Business account with Meta and you sign in with an account that manages it.

## Installing the integration [#integratie-installeren]

1. Go to **Settings > Integrations**
2. Open **WhatsApp Business** in the list (marker **2**)

<DocScreenshot src="/screenshots/communicatie/providers/whatsapp-business-inbox/marketplace-whatsapp.png" alt="Settings > Integrations - WhatsApp Business in the list" />

3. Click **Install** (marker **1**) and complete the Meta OAuth flow

<DocScreenshot src="/screenshots/communicatie/providers/whatsapp-business-inbox/whatsapp-install.png" alt="WhatsApp Business detail - Install" />

4. Choose which **WhatsApp number** receives inbox messages
5. Save the settings

After installation, Tillor receives incoming messages automatically. Replies you also send through the WhatsApp Business app or a linked device appear in the inbox. Messages you send through Tillor are not shown twice.

## What happens next? [#wat-gebeurt-er-daarna]

- Incoming messages appear in the [inbox](/inbox) automatically, linked to the customer with the same phone number.
- You send replies in Tillor. Outside the 24-hour window they go as a paid template, see [Reading and replying to conversations](/inbox/gesprekken#whatsapp-en-het-antwoordvenster-van-24-uur).

## Problems? [#problemen]

<Accordions>
<Accordion title="No messages are coming in">
Check under <UIPath>Settings > Integrations > WhatsApp Business</UIPath> that the correct **WhatsApp number** has been chosen and that the settings have been saved.
</Accordion>
<Accordion title="My replies are not sent outside the reply window">
Add a payment method for your WhatsApp Business account in Meta WhatsApp Manager. Without a payment method, Tillor blocks paid replies.
</Accordion>
</Accordions>

## Related [#gerelateerd]

<Cards>
  <Card title="Inbox" href="/inbox" description="Reading and replying to conversations" />
  <Card title="Messenger" href="/inbox/messenger" description="Facebook Messenger for the inbox" />
</Cards>


# Overview (/en-GB/integraties)

An integration connects Tillor to another service, for example for payments, accounting, telephony, cameras or your Google listing. You manage them all in <UIPath>Settings > Integrations</UIPath>. How to install one is described in [Installing an integration](/integraties/integratie-installeren).

<Requires permission="View integrations" />

## How does this fit together? [#hoe-hangt-dit-samen]

An integration belongs to your whole organisation, not to one user. After installing, the connection works where it is needed: the camera connection at access points, the email connection on the customer profile, the payment connection on invoices. Some connections run through the connector, a small program on a computer in your own network. It must then be online.

```mermaid
flowchart LR
  A[Instellingen > Integraties] --> B[Integratie installeren]
  B --> C[Betalingen en facturen]
  B --> D[Klantprofiel en inbox]
  B --> E[Toegangspunten en camera's]
  E -. via .-> F[Connector in je netwerk]
```

<Callout type="info" title="Good to know">
- Viewing is possible with the **View integrations** permission. Installing, changing and uninstalling require **Manage integrations**.
- Uninstalling cannot be undone. You then install the integration again and fill in the details again.
- Partoo receives your opening hours for the next 90 days and an update every night. See [Partoo](/integraties/partoo).
- Payments made more than 24 hours ago no longer get a camera overlay. See [UniFi Protect](/integraties/unifi-protect).
- Which integrations you see depends on your organisation. Is one missing? Ask your Tillor administrator or support.
</Callout>

## Available integrations [#beschikbare-integraties]

| Integration | What for | Details |
|---|---|---|
| Mollie | Online and card terminal payments, SEPA direct debit | [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie) |
| Bank accounts | Import bank transactions and link them to invoices | [Ponto and bank accounts](/boekhouden/betalingsrapporten/betaalmethodes/ponto) |
| Admisol | Send payment reports to your accounting | [Admisol](/boekhouden/betalingsrapporten/boekhoudsystemen/admisol) |
| Odoo | Export customers and invoices to Odoo | [Odoo](/boekhouden/betalingsrapporten/boekhoudsystemen/odoo) |
| ICY | Read meters | [Meter management](/meterbeheer) |
| Voys | Link phone calls to customers | [Voys](/communicatie/providers/voys) |
| WhatsApp Business | WhatsApp messages in the inbox | [WhatsApp Business](/inbox/whatsapp-business-inbox) |
| Messenger | Facebook Messenger conversations in the inbox | [Messenger](/inbox/messenger) |
| Instagram | Instagram Direct conversations in the inbox | [Instagram](/inbox/instagram) |
| Website chat | Live chat on your website | [Website chat](/inbox/website-chat) |
| Inbox AI assistant | Automatically answer frequently asked questions | [Inbox AI assistant](/inbox/inbox-ai-assistant) |
| UniFi Protect | Link cameras to access points and payments | [UniFi Protect](/integraties/unifi-protect) |
| Partoo | Keep opening hours the same on Google and other listings | [Partoo](/integraties/partoo) |
| Outlook | View a customer's email on the customer profile | [Outlook](/integraties/outlook) |

## Terms [#begrippen]

- **Integration**: a connection between Tillor and an external service.
- **Connector**: the program in your network that links devices such as cameras and printers to Tillor. See [Connector](/connector).
- **Installing and uninstalling**: switching a connection on or removing it. Removing cannot be undone.
- **API key**: a secret code with which Tillor may work in another service.
- **Overlay**: text that runs over camera footage, for example a payment.

More explanation is in the [glossary](/begrippen).

<Cards>
  <Card title="Installing an integration" href="/integraties/integratie-installeren" description="Search, fill in and connect" />
  <Card title="UniFi Protect" href="/integraties/unifi-protect" description="Camera footage at access and payments" />
  <Card title="Partoo" href="/integraties/partoo" description="Send opening hours automatically" />
  <Card title="Outlook" href="/integraties/outlook" description="Customer email on the customer profile" />
</Cards>


# Installing an integration (/en-GB/integraties/integratie-installeren)

You install an integration in <UIPath>Settings > Integrations</UIPath>. You search for it, fill in the details of the external service and click **Install**. After that you adjust it in the **Settings** block or remove it with **Uninstall**. What is available is listed in the [overview](/integraties).

<Requires permission="Manage integrations" />

Before you start:

- With only the **View integrations** permission you can see the list and the settings, but you cannot change anything.
- Have the login details or keys of the external service at hand. For Outlook you are redirected to log in there yourself.
- For a connection that runs through the connector, such as UniFi Protect, the connector must be online.

## Installing an integration [#een-integratie-installeren]

<Steps>
<Step>
### Find the integration [#zoek-de-integratie]
Use the search bar, or choose a category on the left under **Integrations**: **Communication**, **Surveillance**, **Payments**, **Accounting** or **Meters**. **All integrations** shows everything. An integration that is already connected has the **Connected** label.

<DocScreenshot src="/screenshots/integraties/integrations-overview.png" alt="Settings > Integrations with the list of integrations" />
</Step>
<Step>
### Open the integration [#open-de-integratie]
Click it. Some pages have a **View documentation** link at the top.
</Step>
<Step>
### Fill in the details and click Install [#vul-de-gegevens-in-en-klik-op-installeren]
What you fill in differs per service. For Outlook you are redirected to the service itself to log in.
</Step>
</Steps>

## Adjusting or removing [#aanpassen-of-verwijderen]

After installing, the same page shows a **Settings** block. Adjust the connection there and save. With **Uninstall** you remove the connection. This cannot be undone.

## What happens next? [#wat-gebeurt-er-daarna]

- The connection works immediately for your whole organisation.
- What the connection does shows up where it belongs, for example on the customer profile or at an access point.
- After **Uninstall** the connection stops. What is already in the other service stays there.

## Problems? [#problemen]

<Accordions>
<Accordion title="I see No integrations found">
No integration matches your search term or category. Try another search term or choose **All integrations**. If an integration you expect is missing, it is not enabled for your organisation. Ask support.
</Accordion>
<Accordion title="The Install button is greyed out or missing">
You do not have the **Manage integrations** permission. Ask your administrator.
</Accordion>
<Accordion title="Tillor says Could not connect">
The integration could not be connected. Check the details you entered and try again.
</Accordion>
<Accordion title="Tillor says Could not disconnect">
Try again. If that does not work, email support@tillor.eu.
</Accordion>
<Accordion title="Tillor says Failed to update app settings">
Your change was not saved. Try saving again.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Overview of integrations" href="/integraties" description="All available connections" />
  <Card title="Connector" href="/connector" description="The program on your network" />
</Cards>


# Connecting Outlook (/en-GB/integraties/outlook)

With the Outlook connection you see on the customer profile the emails your organisation has exchanged with that customer. Tillor fetches them live from Outlook and does not store them itself.

<Requires permission="Manage integrations" />

Before you start:

- You need a Microsoft account whose mail Tillor may read.
- To see the mail on the customer profile, you need the **View inbox** permission. Without that permission the **Outlook** tab is missing.

## Installing [#installeren]

<Steps>
<Step>
### Open the integration [#open-de-integratie]
Go to <UIPath>Settings > Integrations > Outlook</UIPath>.
</Step>
<Step>
### Click Install [#klik-op-installeren]
You are redirected to Microsoft.
</Step>
<Step>
### Log in and give permission [#log-in-en-geef-toestemming]
Log in with the account whose mail Tillor may read.

<DocScreenshot src="/screenshots/integraties/integrations-outlook.png" alt="Installing Outlook" />
</Step>
</Steps>

After connecting, under **Settings** you see the name, email address and username of the connected account, and until when the connection is active.

## Choosing mailboxes [#mailboxen-kiezen]

By default Tillor only searches the mailbox of the connected account. Under **Mailboxes** you choose extra mailboxes, for example a shared reception mailbox.

- **Personal** is the mailbox of the connected account.
- **Shared** are shared mailboxes that account can open. Tillor looks them up itself.
- **Added manually** are addresses you type yourself. Type the address and choose **Add [address]**.

## Mail on the customer profile [#mail-op-het-klantprofiel]

An **Outlook** tab appears on the customer profile, between **Communication** and **Events**. The tab is only there if Outlook is connected and you have the **View inbox** permission.

- At the top you see the number of messages and the mailboxes that were searched. With **Refresh** you fetch the latest mail.
- Tillor searches on the email address of the customer and of their contacts. If nobody has an email address, it says there is nothing to search for.
- Each message shows the subject, whether it is **Received** or **Sent**, from whom to whom, and a paperclip for attachments. Click a message to open the text and the attachments. With **Open in Outlook** you go to the message in Outlook itself.
- The same mail in several mailboxes appears only once in the list.

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor only reads along and stores nothing. If you remove the connection, the **Outlook** tab disappears from the customer profile.

## Problems? [#problemen]

<Accordions>
<Accordion title="Account details unavailable">
Tillor could not fetch the connected Microsoft account. Refresh the page or reconnect Outlook via **Install**.
</Accordion>
<Accordion title="Reconnect to find shared mailboxes">
Outlook was connected before Tillor could look up shared mailboxes. Click **Reconnect Outlook**, or type the address of the shared mailbox yourself.
</Accordion>
<Accordion title="Shared mailboxes could not be loaded">
You can still type a mailbox address manually under **Added manually**.
</Accordion>
<Accordion title="Outlook mail unavailable">
Tillor could not load any mail from Outlook. Try again with **Refresh** or check the connection.
</Accordion>
<Accordion title="Some mailboxes could not be searched">
The connected account has no access to that mailbox. Check the mailbox permissions in Outlook.
</Accordion>
<Accordion title="I do not see an Outlook tab on the customer profile">
Outlook is not connected, or you lack the **View inbox** permission.
</Accordion>
<Accordion title="This message could not be loaded">
Try opening the message again. If that does not help, use **Open in Outlook** to go to the message itself.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" description="The customer profile and its tabs" />
  <Card title="Integrations" href="/integraties" description="All available connections" />
</Cards>


# Connecting Partoo (/en-GB/integraties/partoo)

Partoo manages your listings on Google and other sites. With this connection Tillor sends your opening hours to your Partoo location, so you do not have to maintain them in two places. You manage the hours themselves in Tillor, see [Organisation settings](/gebruikers/organisaties#openingsuren).

<Requires permission="Manage integrations" />

Before you start:

- In Partoo, create a separate user for Tillor, without two-step login. Tillor cannot log in with two-step authentication.
- Enter your opening hours in Tillor, see the Opening hours heading in the organisation settings.

## Installing [#installeren]

<Steps>
<Step>
### Open the integration [#open-de-integratie]
Go to <UIPath>Settings > Integrations > Partoo</UIPath>.
</Step>
<Step>
### Fill in the details of the Partoo user [#vul-de-gegevens-van-de-partoo-gebruiker-in]
Fill in the **Email** and **Password** of that user.
</Step>
<Step>
### Choose your location [#kies-je-vestiging]
The list of locations only appears after the email and password have been filled in. Under **Location** choose your location. Type to search under **Search locations…**.
</Step>
<Step>
### Click Install [#klik-op-installeren]

<DocScreenshot src="/screenshots/integraties/integrations-partoo.png" alt="Installing Partoo" />
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

Tillor sends your weekly hours, seasons and exceptional days from the [opening hours of your organisation](/gebruikers/organisaties#openingsuren):

- The weekly hours are those of the current week. Partoo has no seasons, so Tillor sends the hours of the season that applies now.
- Days in the next 90 days whose hours differ, such as another season, a public holiday or an exception, are sent as separate dates. A closed period becomes one period.
- Tillor sends this every night and immediately after every change to the opening hours, the time zone, the default country or the connection itself. Only what differs from Partoo is changed.

## Adjusting or removing [#aanpassen-of-verwijderen]

Adjust the email, password or location in the **Settings** block. Leave the password empty to keep the current one. With **Uninstall** the forwarding stops. What is already in Partoo stays there.

## Problems? [#problemen]

<Accordions>
<Accordion title="Partoo rejected this email or password">
Check the details of the Partoo user. If that user has two-step login turned on, turn it off or create a separate user.
</Accordion>
<Accordion title="This Partoo user cannot see any location">
In Partoo, give the Partoo user access to your location and then look again.
</Accordion>
<Accordion title="The locations could not be loaded from Partoo">
Try again in a moment. If it persists, email support@tillor.eu.
</Accordion>
<Accordion title="The hours on Google are not correct">
First check the opening hours in Tillor, the time zone and the default country. After a change Tillor sends them immediately, and again every night.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Organisation settings" href="/gebruikers/organisaties" description="Opening hours, seasons and exceptions" />
  <Card title="Integrations" href="/integraties" description="All available connections" />
</Cards>


# Connecting UniFi Protect (/en-GB/integraties/unifi-protect)

With the UniFi Protect connection you get from an access attempt or an access point event to the recording of the matching camera in one click. Cash payments and card payments can also run as text over the footage of a camera, so you can look back when the till does not balance. Installing is the same as for every integration, see [Installing an integration](/integraties/integratie-installeren).

<Requires permission="Manage integrations" />

Before you start:

- The cameras are read on your park through the [connector](/connector). It must be online. If it is not, Tillor reports **The Tillor connector is offline or unreachable.**
- You need the details of your UniFi OS console. That is the box or server UniFi Protect runs on.
- For the connection with access points, those access points must exist, see [Access control](/toegangscontrole).

## Installing [#installeren]

<Steps>
<Step>
### Open the integration [#open-de-integratie]
Go to <UIPath>Settings > Integrations > UniFi Protect</UIPath>.
</Step>
<Step>
### Fill in the console [#vul-de-console-in]
- **Console host**: the local IP address or hostname of your UniFi OS console.
- **API key**: a secret code you create in the console, which lets Tillor read cameras.
- **Cloud console ID**: the long ID after `/consoles/` in the unifi.ui.com URL of your console.
</Step>
<Step>
### Choose the payment cameras [#kies-de-betaalcameras]
Under **Cash payments camera** and **POS payments camera** choose a camera, or leave **Do not register**. POS is the card terminal.
</Step>
<Step>
### Click Install [#klik-op-installeren]
As soon as the host and API key are filled in, Tillor loads the cameras from the console.

<DocScreenshot src="/screenshots/integraties/integrations-unifi-protect.png" alt="Installing UniFi Protect" />
</Step>
</Steps>

## Linking cameras to access points [#cameras-koppelen-aan-toegangspunten]

After installing, the **Settings** block contains the **Access point cameras** table. Link each **Access point** to a **Camera**. If the list is empty, add access points first.

After that, the details of an access attempt and of an access point event show the **Open in UniFi Protect** link. It opens the recording around that moment in UniFi Protect, in a new tab.

## What happens next? [#wat-gebeurt-er-daarna]

- If you chose a camera under **Cash payments camera** or **POS payments camera**, Tillor sends every payment that becomes **Paid** to that camera. Cash payments go to the cash camera, card payments on a terminal go to the POS camera.
- Payments that were paid more than 24 hours ago no longer get text over the footage.
- Payments through Mollie only count if they belong to the main Mollie profile.
- If you change the details, save. If you leave the **API key** empty, the existing key stays in use. With **Uninstall** you remove the connection.

## Problems? [#problemen]

<Accordions>
<Accordion title="No cameras found on this UniFi Protect console">
The console has no cameras, or the API key has no access to them. Check the key and whether the cameras are visible in UniFi Protect.
</Accordion>
<Accordion title="Could not fetch cameras from UniFi Protect">
Check the host, the API key and whether the connector is online. Tillor reports: **Check the host, API key, and connector.**
</Accordion>
<Accordion title="The Tillor connector is offline or unreachable">
Cameras are loaded through the connector on your local network. Start the connector or restore the connection, see [Connector](/connector).
</Accordion>
<Accordion title="I do not see Open in UniFi Protect on an access attempt">
No camera is linked to that access point. Link one in the **Access point cameras** table.
</Accordion>
<Accordion title="The payment is not shown over the footage">
Check that the camera under **Cash payments camera** or **POS payments camera** is not set to **Do not register**. A payment that was paid more than 24 hours ago no longer gets an overlay. A Mollie payment only counts for the main profile.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Access control" href="/toegangscontrole" description="Access log and access points" />
  <Card title="Connector" href="/connector" description="The connection to your local network" />
  <Card title="Integrations" href="/integraties" description="All available connections" />
</Cards>


# Map (/en-GB/kaart)

On the map you see at a glance which terrains are free, reserved or occupied, for every day you choose. You also draw the boundaries of your terrains here, so Tillor knows their size, and you measure distances. You manage the terrains themselves under [Terrains](/terreinen).

<Callout type="info" title="Good to know">
- The map always opens on today. Your style, labels and layers are saved, though.
- Checked-out and cancelled reservations do not count for colour, departure label or double booking.
- The labels with nights and departure disappear below zoom level 17.5. The terrain name stays.
- A terrain without a drawn boundary is not on the map. You can only draw with **Edit Mode** on.
- The map opens on the map centre you set under **Settings > Map**. That same point also determines the weather.
</Callout>

## Opening the map [#de-kaart-openen]

Go to <UIPath>Park > Map</UIPath>. You immediately see all terrains with their occupancy status.


<DocScreenshot src="/screenshots/park/map-overview.png" alt="Map with drawn terrain 12" />

- **Green area** - bookable terrain is free
- **Grey area** - terrain is **non-bookable** and has no active stay on the chosen date (no reservation or occupation); nights and departure labels are missing
- **Cyan area** - reservation **booked**, not checked in yet (also on later days in the stay period as long as there is no check-in)
- **Blue area** - reservation **checked in** (active stay on the chosen date)
- **Yellow area** - the terrain has an active occupation (long-term rental; applies on every chosen date as long as the occupation runs)
- **Red area** (light overlay, red border) - double booking: overlapping reservation periods on the same terrain

Click a terrain on the map to open a pop-up with the name, reservations, any active occupation (guest) and shortcuts.

## Choosing a date [#datum-kiezen]

To the right of **Map settings** you choose a **date** (today by default). The map then shows how the terrains look on that day. After a refresh of the page the date is back on **today**; only the other map settings (style, labels, layers) are kept. **Checked out** and **cancelled** reservations do not count for colour, departure label or double booking (they also do not appear in the pop-up on the map). For free pitches a label with a moon icon and the number of nights until the next check-in is shown under the terrain name. For a reservation or occupation with a departure date a label with a departure icon and the number of nights until checkout is shown (0 = today). Hover over a label for the full text. In case of a **double booking** (two or more reservations with overlapping stay periods on the same terrain) the terrain gets a red border and a light red overlay; a red triangle icon appears before the terrain number. In the pop-up you see a warning with the reservations involved. Below zoom level **17.5** the map hides the nights and departure labels automatically; the terrain name stays visible. Zoom in to at least **17.5** (or turn **Nights and checkout** off in the map settings) to see those little labels. When zoomed out, terrain names are shown smaller so they overlap less.

## Layers and colours [#lagen-en-kleuren]

At the bottom left are three buttons: **Layers**, **Export PDF** and **Map settings**, with the date picker to the right of them. With **Layers** you decide what you see and how the terrains are coloured.

<DocScreenshot src="/screenshots/instellingen/map-layers.png" alt="Map with the Layers panel" />

- Under **Colors** you choose **Occupancy** or **Terrain type**. With **Occupancy** the terrains are coloured as described above. With **Terrain type** each terrain gets the **Map color** of its type, see [Terrain types](/terreinen#terreintypes).
- With **Occupancy**, under **Terrain layers** there is a tick per kind: **Free**, **Reserved**, **Checked in**, **Occupied**, **Non-bookable** and **Double booking**. Remove a tick to hide those terrains.
- Under **Terrain types** you choose which types appear on the map. **No type** belongs to terrains without a type.

With **Export PDF** you download a PDF with the terrains that are on the map now: name, size, gas and calculated tariff, on the chosen date.

## Map settings [#kaartinstellingen]

With **Map settings** you adjust the display.

<DocScreenshot src="/screenshots/instellingen/map-settings.png" alt="Map with the Map settings panel" />

| Setting | Description |
|------------|--------------|
| **Style** | **Satellite**, **Hybrid** or **Streets** |
| **Edit Mode** | Show the tools to draw and edit terrain boundaries |
| **Terrain Names** | Show terrain names on the map. Only works if at least one layer is on |
| **Nights and checkout** | Show next to the terrain names how many nights are free and when a stay departs. Only works if **Terrain Names** is on |

Your settings are saved automatically.

## Setting the map default [#kaartstandaard-instellen]

<Requires permission="Edit settings" />

Under <UIPath>Support > Settings > Map</UIPath> you decide where the map opens and how it is rotated.

<DocScreenshot src="/screenshots/instellingen/settings-map.png" alt="Settings > Map" />

| Setting | Description |
|---|---|
| **Map centre** | Click on the map or drag the pin to the middle of your park. The coordinates are shown below it. |
| **Map bearing** | The compass direction in degrees (0-360) in which the map opens. |

The map centre also counts outside the map. It is the place the weather is fetched for under <UIPath>Park > Weather</UIPath>, and address suggestions when you fill in an address give priority to places nearby. If you have not set an **Access point location** under **Apple Wallet**, Apple Wallet and Google Wallet use the map centre for the access pass. See [Organisation](/gebruikers/organisaties#apple-wallet). If the centre is in the wrong place, the weather will not be right either.

## Drawing terrain boundaries [#terreingrenzen-intekenen]

With edit mode you record the exact boundary of a terrain on the map. Tillor calculates the size in m² from it, and the tariff formula uses that.

1. Go to **Park > Map**
2. Click **Map settings** at the bottom left
3. Turn on **Edit Mode**
4. Click the desired points on the map to draw a polygon
5. Close the polygon by clicking the starting point
6. In the dialog, select the terrain you want to link

<DocScreenshot src="/screenshots/park/map-terrain-select-dialog.png" alt="Terrain linking dialog after drawing a polygon" />

7. Click **"Update"**

The terrain now appears as a coloured area on the map.

<Callout type="info">
Terrains without a drawn location are at the top of the selection list, so you can find and link them easily.
</Callout>

## Measuring distances [#afstanden-meten]

With the measuring tool you can quickly measure distances and areas on the map - handy when laying out the site or estimating distances between locations.

1. At the top left of the map click **Measure Distance** or **Measure Area**
2. Place points on the map (close an area by clicking the starting point)
3. The measurement is shown on the map; use **Clear Measurements** to start over

## Opening a terrain from the map [#een-terrein-openen-vanaf-de-kaart]

Via the map you can quickly navigate to a terrain:

1. Click a terrain on the map
2. The pop-up shows the name, occupancy status, active reservations and, for an occupation, the guest
3. Click **"View details"** to go to the detail page
4. As long as there is no active occupation, you can start **"Create reservation"**

## What happens after drawing? [#wat-gebeurt-er-na-het-intekenen]

- The terrain gets a colour on the map and Tillor fills in the **Surface area** on the terrain page.
- The **Calculated tariff** is recalculated, because the size counts. See [Terrains](/terreinen#hoe-het-tarief-tot-stand-komt).
- The **Total Surface Area** at the top of the terrain list now includes the terrain.

## Problems? [#problemen]

<Accordions>
<Accordion title="My terrain is not on the map">
The terrain has no drawn boundary yet. Turn on **Edit Mode**, draw the terrain and choose it in the dialog. Terrains without a location are at the top of the selection list. If the terrain is there, check under **Layers** whether the layer of its status is on.
</Accordion>
<Accordion title="The labels with nights and departure are missing">
Zoom in to at least level 17.5 and check in **Map settings** that both **Terrain Names** and **Nights and checkout** are on. Grey, non-bookable terrains without a stay never have such a label.
</Accordion>
<Accordion title="The map opens in the wrong place or shows the wrong weather">
The map centre is wrong. Move the pin under <UIPath>Support > Settings > Map</UIPath>.
</Accordion>
<Accordion title="I do not see Create reservation in the pop-up">
That option is only there if the terrain has no active occupation.
</Accordion>
<Accordion title="The map shows today's date, even after my choice">
The chosen date is not saved. After a refresh the map is back on today.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Terrains" href="/terreinen" description="Create terrains, tariff and meters" />
  <Card title="Reservations" href="/reserveringen" description="Plan and manage stays" />
  <Card title="Park" href="/park" description="Park management overview" />
</Cards>


# Customer management (/en-GB/klantenbeheer)

A customer is the place in Tillor where everything about a person or company comes together: details, contacts, invoices, occupations, reservations, documents and access. You create a customer, find them again in the list and update their details on the customer profile. Start with [Adding a new customer](#een-nieuwe-klant-toevoegen).

<Callout type="info" title="Good to know">
- When creating, only the **First Name** is required. You fill in all other details later on the customer profile.
- Tillor warns about a **possible duplicate customer** if first and last name together, the email address or the phone number already belong to another customer. An email address or phone number counts from 4 characters.
- Address suggestions appear from 3 typed characters in the **Street** field.
- Tillor deletes scans of identity documents without a linked customer after 7 days.
- Deleting a customer also removes all related data and cannot be undone.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

Everything you register in Tillor hangs on a customer. An occupation links the customer to a terrain, and therefore also to the meters on that terrain. The consumption of those meters ends up on the customer's invoice.

```mermaid
flowchart LR
  K[Klant] --> C[Contactpersonen]
  K --> R[Reserveringen]
  K --> B[Bezettingen]
  B --> T[Terrein]
  T --> M[Meters]
  M --> V[Verbruik]
  V --> F[Facturen]
  K --> F
  F --> P[Betalingen]
  K --> D[Documenten en ondertekenverzoeken]
  K --> O[Opmerkingen en taken]
```

## Adding a new customer [#een-nieuwe-klant-toevoegen]

Before you start:

- An identity scan, if you want to create the customer with it. If there is no scan in the queue, simply choose to enter the details by hand.
- Not sure whether the customer already exists? Search for them in the list first, see [Searching and filtering customers](#klanten-zoeken-en-filteren).

<Steps>
<Step>
### Open the customer list [#open-de-klantenlijst]
Go to <UIPath>Customers > Overview</UIPath> and click **Create new customer** at the top right. As long as there are open identity scans, the button shows a menu with **Manual** and the scans from the queue.

<DocScreenshot src="/screenshots/klanten/customer-create-scan-menu.png" alt="Create new customer with the menu for an open identity scan" />
</Step>
<Step>
### Choose how to create the customer [#kies-hoe-je-de-klant-aanmaakt]
<Tabs items={["By hand", "From an identity scan"]}>
<Tab value="By hand">
Choose **Manual**. A form opens with **First Name**, **Last Name**, **Email address** and **Phone number**. Fill in what you know and click **Create customer**. If a customer with similar details may already exist, a yellow message with a link to that customer appears at the bottom.

<DocScreenshot src="/screenshots/klanten/customer-create-dialog.png" alt="Create new customer dialog (Manual)" />
</Tab>
<Tab value="From an identity scan">
Choose a scan from the menu, for example **Lotte Peeters**. In the confirmation you see a preview of the document (front, back, portrait) and the details from the machine-readable zone. Click **Create customer**. Tillor creates the customer, links the scan and fills in the details from the document.

<DocScreenshot src="/screenshots/klanten/customer-create-from-scan-confirm.png" alt="Confirmation after choosing an open identity scan" />

Open scans are also shown in the panel at the bottom right, with **Make customer based on scan**. More about scans is under [Identity scans](/identiteitsscans).

<DocScreenshot src="/screenshots/klanten/identity-scan-dock.png" alt="Panel at the bottom right with an open identity scan" />
</Tab>
</Tabs>
</Step>
<Step>
### Check for a duplicate customer [#controleer-op-een-dubbele-klant]
If a customer with the same name, email address or phone number may already exist, Tillor shows **Possible duplicate customer** with the name and customer number. Click **Use this customer** to open that customer, or **Create anyway** if it really is a different person.
</Step>
</Steps>

<Callout type="warn" title="Retention period and responsibility">
Tillor deletes scans without a linked customer **automatically after 7 days**. Process them in time.

For **linked** scans, **your organisation** decides the retention period and legal basis. Tillor keeps them until you unlink or delete them. Compliance with privacy legislation and appropriate retention periods are **your responsibility** as data controller.
</Callout>

### What happens next? [#wat-gebeurt-er-daarna]

- You land on the new customer profile, where you fill in the rest: address, VAT number, contacts and custom fields.
- If the customer was created from a scan, that scan belongs to the customer and is no longer in the queue.
- The creation is the first line on the customer's **Events** tab.
- If you want something to happen right away for a new customer, for example a welcome email, use an [automation](/automatiseringen).

## Checking a VAT number [#een-btw-nummer-controleren]

On the **Overview** tab, in the **Customer Details** block, you fill in the **VAT Number**. Tillor checks the number with the European VIES register as soon as **Country** is also filled in and the number is long enough.

- If the number is valid, you see a green tick and a window with the official company name and the address from VIES. Click **Apply company address** to copy that address into the form.
- If the number is invalid, you see a red icon and an error message.

## The customer profile [#het-klantprofiel]

When you click a customer, you see the customer profile. At the top are summary customer details, with the pinned comments below. Via the tabs you reach the rest.

<DocScreenshot src="/screenshots/klanten/customer-profile.png" alt="Customer profile - Customer Details block" />

| Tab | What you find there |
|---|---|
| **Overview** | Customer details (editable form), recent communication, invoices, readings, comments, occupations and notifications |
| **Invoicing** | All invoices of this customer, and the [balance per ledger](/producten/product-aanmaken#het-saldo-van-de-klant-bewaken) |
| **Access Control** | Access rights and licence plates |
| **Contacts** | Extra contacts |
| **NFC Tags** | Linked NFC tags |
| **Reservations** | All reservations |
| **Communication** | Messages and communication history |
| **Outlook** | Mail from and to the customer from your Outlook mailboxes. This tab only appears if [Outlook](/integraties/outlook) is connected and you may **View inbox** |
| **Events** | Timeline with changes, including creating a customer or contact, assigning or unassigning an identity document, and before/after for customer, contact, invoicing setting and access method updates |
| **Documents** | Stored files and attachments, and the [signature requests](/handtekeningen) |
| **Tasks** | Tasks linked to this customer |

<DocScreenshot src="/screenshots/klanten/customer-access-control.png" alt="Customer profile - Access Control tab with access methods" />

### At a glance [#in-één-oogopslag]

On the **Overview** tab, the **At a glance** card is at the top left. It only shows what needs attention at that moment and collapses when there is nothing to show:

- **Active reservations** and **Upcoming reservations**, with a **View reservation** button
- **Active meters with alarms**
- **Open tasks** of this customer
- **Identity scans** of this customer

<DocScreenshot src="/screenshots/klanten/customer-key-info.png" alt="Customer profile - At a glance card" />

You see the same details in the card of an incoming call. A comment you pin appears directly under the customer details at the top of the profile. See [Comments](/notities#opmerking-vastzetten).

### Birthdays [#verjaardagen]

If the customer or their partner has a birthday today, a green **Birthday today** block appears at the top of the customer profile, with the name and the age, and confetti falls over the page. For the customer, the date comes from the **Date of birth** field. The partner is the contact with the relationship **Partner**. A date of birth of 29 February counts as 28 February in years without a leap day.

## Editing customer details [#klantgegevens-bewerken]

On the **Overview** tab, in the **Customer Details** block, you adjust fields. At the bottom of the form are **Cancel** and **Save**. Every change appears on the **Events** tab, with a **Before / after** overview per field, so you can see exactly what was changed.

If your organisation has created [custom fields](/eigen-velden) for customers, they appear as extra fields in the same block.

### Filling in the address [#adres-invullen]

The address consists of **Street**, **No.** and **Box**, followed by **Postal code**, **City** and **Country**.

<DocScreenshot src="/screenshots/klanten/customer-address-input.png" alt="Address field with street, number and box" />

- If you type at least three characters of the street, Tillor suggests addresses. Choose one: street, number, postal code, city and country are then filled in. The suggestions come from OpenStreetMap, a free map database.
- If you type **Kerkstraat 5** in the **Street** field, the number jumps to **No.**. A space after the number takes you to **Box**. If you paste a complete address, it is split up as well. In countries where the number comes before the street, the number is not moved automatically.
- If postal code or city is already filled in, Tillor checks the address. A green tick with **Address found** means the address exists. A yellow icon with **Suggested spelling** shows the usual spelling. Click **Update address** to adopt it.
- The address is stored as a single line, for example on invoices and in exports.

Suggestions are a help, not an obligation. You can always fill something in yourself.

## Searching and filtering customers [#klanten-zoeken-en-filteren]

Go to <UIPath>Customers > Overview</UIPath>. At the top is a search bar.

<DocScreenshot src="/screenshots/klanten/customers-list.png" alt="Customer list with search bar" />

- Type a name, email address, phone number or customer number.
- Results are updated while you type, with a short delay.
- You can also filter on **Created** (date range), **Status** and **Type**.

## Deleting a customer [#een-klant-verwijderen]

Use **Delete Customer** in the menu at the top of the customer profile. Tillor asks **Are you sure you want to delete this customer?** If you confirm, all related data disappears as well. This cannot be undone.

## Common scenarios [#veelvoorkomende-scenarios]

### A new customer books for the first time [#een-nieuwe-klant-boekt-voor-het-eerst]

1. The customer calls or books online.
2. You add the customer with **Create new customer**.
3. You fill in the address and other details on the customer profile (**Overview** tab > **Customer Details**).
4. You create an occupation on the desired terrain, see [Occupations](/bezettingen#een-bezetting-aanmaken).
5. Tillor keeps track of the consumption of the linked meters automatically. You see it under **Readings** on **Overview**.

### Changing customer details [#klantgegevens-wijzigen]

Open the customer profile, adjust the address in the form and click **Save**.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says: Customer not created">
The message is **The customer could not be created.** Check that **First Name** is filled in and that the email address is a valid address, with an at sign and a domain. Then try again.
</Accordion>
<Accordion title="Tillor says: Possible duplicate customer">
A customer with the same first and last name, the same email address or the same phone number already exists. Click **Use this customer** if it is the same person, or **Create anyway** if it is a different person.
</Accordion>
<Accordion title="Tillor says: Something went wrong. The customer could not be updated">
Your changes were not saved. Check the form for an invalid email address or an empty required field, and click **Save** again.
</Accordion>
<Accordion title="The scan is not in the Create new customer menu">
Only scans without a linked customer count as open. If the scan is already linked to a customer, or older than 7 days, it is no longer there. See [Identity scans](/identiteitsscans).
</Accordion>
<Accordion title="Make customer based on scan is greyed out">
The scan shows the reason. Usually the scan has no first name: *fill it in on the scanner or link this scan manually*. Or a customer with the same national register number already exists. Then open that customer and link the scan to them.
</Accordion>
<Accordion title="Tillor says: Invalid VAT Number">
The number is not valid or not registered in VIES. Check that the **Country** is right and that the number is complete. Tillor also reports **VAT number must be at least ... characters** if the number is too short for the chosen country, and asks for both a number and a country if one of the two is missing.
</Accordion>
<Accordion title="I do not see the Outlook tab">
The tab only appears if [Outlook](/integraties/outlook) is connected and you have the **View inbox** permission.
</Accordion>
<Accordion title="No address suggestions appear">
Type at least three characters in the **Street** field. If the suggestions stay away, simply fill in the address yourself.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Customer**: the record in Tillor of a person or company. See [customer](/begrippen#klant).
- **Contact**: an extra person on a customer, for example a partner or emergency contact.
- **Occupation**: a customer on a terrain for a period. See [occupation](/begrippen#bezetting).
- **Reservation**: a booking for a stay. See [reservation](/begrippen#reservering).
- **Events**: the timeline with all changes on a customer. See [event](/begrippen#gebeurtenis).
- **VIES**: the European register in which Tillor checks a VAT number.

## See also [#zie-ook]

<Cards>
  <Card title="Identity scans" href="/identiteitsscans" description="Create a customer from a scan, retention period and connector" />
  <Card title="Occupations" href="/bezettingen" />
  <Card title="Reservations" href="/reserveringen" />
  <Card title="Invoices" href="/facturen" />
  <Card title="Terrains" href="/terreinen" />
  <Card title="Winning a seasonal customer" href="/praktijk/seizoensklant-binnenhalen" />
</Cards>


# Alarms and meter status (/en-GB/meterbeheer/alarmen-en-status)

A meter raises an alarm when it reports a deviation, such as a connection problem or a technical fault. Here you read where you see that, what the status indicator means and how to clear an alarm.

## Following up on an alarm [#een-alarm-opvolgen]

<Steps>
<Step>
### Find the meter with an alarm [#zoek-de-meter-met-een-alarm]
Go to <UIPath>Park > Meters</UIPath>. A meter with an active alarm has a small triangle.
</Step>
<Step>
### Open the meter and read the alarm [#open-de-meter-en-lees-het-alarm]
In the list of alarms you see for each alarm the message, **Started At**, and whether it is Active or Resolved. The message depends on the type of meter and the provider.
</Step>
<Step>
### Fix the problem [#los-het-probleem-op]
Check the battery and the signal in the meter details, and visit the meter if necessary.
</Step>
<Step>
### Clear the alarm [#wis-het-alarm]
In the meter's action menu choose **Clear alarms**.
</Step>
</Steps>

## What the status means [#wat-de-status-betekent]

- **Status indicator**: smart meters (ICY and Tillor Hydrodigit) show whether they have communicated recently and whether there are alarms. The indicator changes colour when there is an active alarm or when the meter has sent nothing for more than a day.
- **Battery level** and **signal quality**: as a percentage in the meter details, for meters that report them.

## ICY controllers [#icy-controllers]

The ICY modules on the pitches communicate through a controller in the meter cabinet. If a controller drops out, no meter behind that controller sends anything any more.

If your park has ICY meters, the **ICY controllers** card is shown above the list in <UIPath>Park > Meters</UIPath>. It says how many controllers there are, how many ICY has not seen in the last hour and how many alarms are open on controllers. Click **Show** for the table:

- **Controller**: the name of the meter cabinet that holds most of the controller's meters, with a green or red dot. If the name at ICY differs from it, the ICY name is shown next to it in grey. If the meters are in no meter cabinet at all, you only see the ICY name.
- **Meters**: how many of your meters communicate through this controller. On a meter itself, that name is under **Controller** in the **Information** card.
- **Alarms**: the alarms ICY reports on the controller itself, with the time since when. An alarm disappears from the list as soon as ICY no longer reports it; you do not need to clear it. An alarm that Tillor does not know by name yet is shown as **Unknown alarm** with the ICY code. Anyone who receives push notifications for meter alarms also gets a notification for a new and for a resolved alarm on a controller.
- **Last seen**: when ICY last saw the controller. If that was more than an hour ago, the time is shown in red.

A controller with an alarm or a controller that has been silent for more than an hour is at the top, and the card then opens by itself.
Tillor updates the list every time the ICY meters are read.

## When all your meters go silent at once [#als-al-je-meters-tegelijk-stilvallen]

Tillor Hydrodigit and Tillor EM300 meters send their reading to Tillor through a receiver, the LoRa gateway. Normally they send a measurement about twice a day. If every recently active LoRa meter of your organisation has sent nothing for more than 24 hours, the cause is probably the gateway or the connection with Tillor and not the meters. A single silent meter does not trigger this notification: at least two active meters are needed.

The Tillor administrators then receive a notification, with the last reading received and the meters involved. Those meters are then not listed again separately as a meter needing attention. You do not need to set anything up. If you see a common, old **Last reading** on your meters, contact support.

## What happens next? [#wat-gebeurt-er-daarna]

- A cleared alarm no longer shows as active in the list. The triangle next to the meter in <UIPath>Park > Meters</UIPath> only belongs to active alarms.
- If the meter reports the problem again, you get a new alarm.

## Problems? [#problemen]

<Accordions>
<Accordion title="The alarm keeps coming back">
The cause is still there. Check the battery, signal and the location of the meter, and call support if necessary.
</Accordion>
<Accordion title="Several meters have no recent reading">
Check whether they all have an old **Last reading**. Then the gateway or the connection is the cause. Contact support.
</Accordion>
<Accordion title="A group of ICY meters stops sending at the same time">
In the **ICY controllers** card, check whether a controller has an alarm or is shown in red. Then the cause is that controller or its connection and not the meters. Check the power and the network of the meter cabinet and contact ICY if necessary.
</Accordion>
<Accordion title="One meter has stopped sending, but no notification comes">
The gateway notification needs at least two active meters. Look yourself at the status, the battery and the signal of that meter.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Viewing meter readings and trends" href="/meterbeheer/meterstanden-en-trends" />
  <Card title="Invoicing consumption" href="/meterbeheer/verbruik-factureren" />
</Cards>


# Consumption batches (/en-GB/meterbeheer/consumptie-batches)

This page explains how Tillor divides a customer's consumption into periods, so you know why an amount looks the way it does. A **consumption batch** (or consumption period) is a period of meter consumption for one customer and one meter. Tillor automatically keeps track of when a period starts, when it ends and whether it has already been invoiced. If you only want to invoice, go to [Invoicing consumption](/meterbeheer/verbruik-factureren).

## Life cycle of a batch [#levenscyclus-van-een-batch]

```mermaid
flowchart TD
  A[Created<br/>start reading only] -- readings --> B[Open<br/>start and end reading]
  B -- close --> C[Closed<br/>fixed]
  C -- invoice --> D[Invoiced<br/>completed]
```

### Statuses [#statussen]

| Status | Description |
|--------|-------------|
| **Open** | New readings are added to the period automatically |
| **Closed** | The period is closed and waiting to be invoiced |
| **Invoiced** | The consumption has been processed in an invoice |

## When is a batch created? [#wanneer-wordt-een-batch-aangemaakt]

- **On occupation**: when you link a customer to a terrain with meters and enter a start reading
- **On manual reading**: when you enter a meter reading for a meter on a terrain with an active occupation and there is no open batch yet for that customer and meter combination

## When is a batch closed? [#wanneer-wordt-een-batch-gesloten]

- **When an occupation ends**: when the customer leaves the terrain (the occupation is removed)
- **On a meter correction or reset**: when the meter reading goes down (for example the meter is replaced or corrected). The system closes the previous period, creates a closed "jump" batch with negative consumption (for example -90 for 100→10), and the next reading starts a new open batch
- **On a new occupation**: when another customer (or the same customer again) is linked with explicit start readings

<Callout type="info" title="Meter reading goes down">
If a meter reading goes down (correction, reset or replacement), Tillor automatically closes the running batch, creates a closed "jump" batch with negative consumption, and immediately opens a new batch at the new reading. The jump batch is easy to recognise and to mark as paid. The next reading is added to the new batch.
</Callout>

## Examples [#voorbeelden]

<Accordions type="multiple">
  <Accordion title="Normal occupation (happy flow)">
    A customer takes a terrain, uses consumption and leaves. The most common scenario.

    ```
    1. Occupation created with start reading 100 m³ (15 Jan)
       → Batch: start 100 m³, open

    2. Readings: 150 m³ (20 Jan), 200 m³ (25 Jan)
       → Batch: start 100 m³, end 200 m³, consumption 100 m³

    3. Occupation ended with end reading 250 m³
       → Batch closed: consumption 150 m³, waiting to be invoiced

    4. Invoice consumption
       → Batch invoiced, done
    ```
  </Accordion>

  <Accordion title="Continuous invoicing (happy flow)">
    The occupation continues; you invoice per period without closing the batch.

    ```
    1. Batch: 0 → 50 m³ (open)
    2. Mark as invoiced
       → Batch 1 closed, Batch 2 created automatically: 50 → (open)
    3. New readings: 75, 100 m³
       → Batch 2: 50 → 100 m³, consumption 50 m³
    4. Mark as invoiced again
       → Batch 2 closed, Batch 3: 100 → (open)
    ```
  </Accordion>

  <Accordion title="Meter reading goes down - simple (100 → 10)">
    Start reading only, then a correction. Jump batch with consumption -90 m³, then a new open batch.

    ```
    1. Batch: start 100 m³ (15 Jan), no end reading yet
    2. Reading on 16 Jan: 10 m³ (meter corrected)
       → Batch 1 closed (consumption 0)
       → Jump batch: start 100 m³, end 10 m³ (consumption -90 m³) - closed
       → New open batch: start 10 m³
    3. Next reading: 20 m³ → batch: 10 → 20 m³, consumption 10 m³
    ```
  </Accordion>

  <Accordion title="Meter reading goes down - with consumption (100 → 150 → 10)">
    First normal consumption, then the meter is replaced. Jump batch with consumption -140 m³, then a new open batch.

    ```
    1. Batch: start 100 m³ (15 Jan), end 150 m³ (20 Jan) → consumption 50 m³
    2. Reading on 25 Jan: 10 m³ (meter replaced)
       → Batch 1 closed with end 150 m³ (consumption 50 m³)
       → Jump batch: start 150 m³, end 10 m³ (consumption -140 m³) - closed
       → New open batch: start 10 m³
    3. Next reading: 20 m³ → batch: 10 → 20 m³, consumption 10 m³
    ```
  </Accordion>

  <Accordion title="Period without consumption">
    A reading with the same value as the start. Tillor adjusts the start date.

    ```
    1. Batch: start 982 m³ (1 Dec), open
    2. Reading 5 Jan: 982 m³ (same reading)
       → Start automatically adjusted to 5 Jan
       → Period shows "5 Jan → ..." instead of "1 Dec → ..."
    3. Reading 5 Jan (later): 990 m³
       → Consumption 8 m³, period "5 Jan → 5 Jan"
    ```
  </Accordion>

  <Accordion title="Customer returns">
    A customer leaves the terrain and comes back later. New batch, not linked to the previous one.

    ```
    1. Customer A: batch 0 → 50 m³, occupation ended
    2. Customer B: batch 55 → 100 m³, occupation ended
    3. Customer A returns with start reading 110 m³
       → New batch: start 110 m³ (not 50 m³)
       → No link with the previous period
    ```
  </Accordion>

  <Accordion title="Draft invoice deleted - continuation becomes one batch again">
    You invoiced consumption while the occupation continued; afterwards you delete the draft invoice.

    ```
    1. Open batch: 100 m³ (1 Feb) → 200 m³ (7 Mar), occupation continues
    2. Invoice consumption (draft invoice)
       → Batch A: 100 → 200 m³, linked to invoice, closed for that invoice
       → Batch B automatically: start 200 m³ (same reading as the end of A), open
    3. New reading: 250 m³ (15 Mar)
       → Batch B: 200 → 250 m³
    4. Delete the draft invoice
       → Batch A: no longer linked to an invoice, not invoiced
       → Batch B (still starting at 200 m³) is merged into A
       → Result: one open batch 100 m³ → 250 m³, ready to be invoiced again
    ```
  </Accordion>

  <Accordion title="Draft invoice deleted - no merge (different start)">
    Two separate periods on the same meter: the second batch does **not** start at the end reading of the first. Tillor does **not** merge them.

    ```
    1. Batch A: 12.49 m³ → 13.21 m³ (end reading = reading X)
    2. Later another period / jump on the meter
    3. Batch B: 0.10 m³ → 0.77 m³ (start = reading Y, Y ≠ X)
    4. Same or different invoice - it does not matter for this example
    5. If you delete an invoice that only belonged to A:
       → A is released for invoicing again
       → Batch B remains; it is not pulled into A (start Y is not the same as end X)
    ```
  </Accordion>

  <Accordion title="Draft invoice deleted - continuation already invoiced again">
    The first invoice covers the period up to reading X; then new readings and a **second** invoice on the continuation. Deleting the first invoice does not change the second.

    ```
    1. Invoice 1: batch A 0 → 50 m³ → after invoicing batch B: start 50 m³, open
    2. Readings: 60, 75 m³ on batch B
    3. Invoice 2: batch B invoiced → batch C: start 75 m³
    4. Delete invoice 1
       → A released again
       → B still belongs to invoice 2 → is not seen as an "open continuation of A"
       → No merge of A with B; C remains the active continuation after invoice 2
    ```
  </Accordion>
</Accordions>

## Invoicing [#facturering]

### Way 1: Via the invoice button (new invoice) [#manier-1-via-factuurknop-nieuwe-factuur]

1. Go to **Customers** > customer > tab **Overview** (card **Readings**)
2. Click **Invoice consumption**
3. The system creates an invoice with the consumption as a line, or adds it to an existing draft invoice
4. The batches are marked as invoiced and linked to the invoice

### Way 2: Mark as invoiced manually [#manier-2-handmatig-als-gefactureerd-markeren]

If you invoiced the consumption outside Tillor:

1. Open the batch in the card **Readings** (customer profile) or **Consumption** (**Park** > **Meters** > meter)
2. Click the warning icon next to the period
3. Confirm with **Yes, mark as invoiced**
4. The batch is closed without an invoice link

<Callout type="warn" title="Please note">
Only manually marked batches can be "reverted". Batches that are linked to a real invoice cannot be undone - the invoice must be deleted first.
</Callout>

### Automatic new batch [#automatische-nieuwe-batch]

When you mark a batch as invoiced (and the occupation is still running), Tillor automatically creates a **new open batch** that starts at the end reading of the previous one. That way the consumption continues without gaps.

```
Batch 1: 0 → 50 m³ (invoiced)
         ↓
Batch 2: 50 → (open, ready for new readings)
```

## Deleting an invoice [#factuur-verwijderen]

If you delete a **draft invoice** that had consumption linked to it, Tillor adjusts the consumption batches automatically.

### What always happens? [#wat-gebeurt-er-altijd]

- The link with that invoice disappears.
- The batch is shown as **not invoiced** again and can end up on an invoice again.

### When do two batches become one again? [#wanneer-worden-twee-batches-weer-één]

Sometimes Tillor automatically started a **new open batch** at the **end reading** of the invoiced period after invoicing. If you delete that invoice, the system looks for such a continuation:

| Condition | Result |
|-----------|--------|
| There is another batch with the **same start reading** as the **end reading** of the invoiced batch (same reading as the connection point) | That continuation is **merged** into the original batch. You get one continuous period again. |
| The continuation is **not yet invoiced** (no invoice on it) | Merging is **allowed**. |
| The continuation **starts at a different reading** than the end reading of the invoiced batch | **No** merge: they are two separate periods. |
| The continuation has **already been invoiced again** (another invoice) | **No** merge: that period stays on the other invoice. |

### End reading after merging [#eindstand-na-samenvoegen]

After merging, the batch should be **open** again (if the continuation was open) and the **end reading** is the current end reading of that continuation - so including readings that came in **after** the invoice. If technically there was no end reading on the continuation but there are newer readings on the meter, Tillor fills in the end reading with the **most recent reading after the connection point** (same logic as when a batch is created).

<Callout type="info" title="Manually marked as invoiced">
Only batches **without** an invoice link can be made "not invoiced" again manually using the revert icon (on **Park** > **Meters** > meter, for settled periods). Batches attached to a real invoice follow the rules above only **after** you delete that invoice.
</Callout>

## Specific situations [#specifieke-situaties]

### Period without consumption [#periode-zonder-verbruik]

If a reading comes in with the same value as the start (consumption = 0), Tillor automatically adjusts the start date. The period shown only covers the time in which consumption actually took place.

### Customer returns [#klant-keert-terug]

When a customer occupies a terrain again after leaving earlier:

- A **completely new batch** is created
- The batch does not start where the previous one ended
- You choose a start reading again (or the meter reading at that moment)

### Meter linked to several customers [#meter-gekoppeld-aan-meerdere-klanten]

Each customer and meter combination has its own batches. The same terrain can have several occupations (for example different periods), each with its own consumption periods.

## Overview in the application [#overzicht-in-de-applicatie]

Where you see batches:

- **Customers** > customer > tab **Overview** > card **Readings**: per meter only **outstanding** periods (orange accent) with the button **Invoice consumption** at the top.
- **Park** > **Meters** > meter > card **Consumption**: per customer first outstanding periods (orange), below them settled periods (green when linked to an invoice, grey when marked manually).
- **Customers** > **Outstanding Consumption**: table of customers who still have consumption to invoice.


<DocScreenshot src="/screenshots/meterbeheer/outstanding-consumption.png" alt="Customers > Outstanding Consumption" />

## See also [#zie-ook]

<Cards>
  <Card title="Meter management" href="/meterbeheer" description="Back to the overview" />
  <Card title="Invoicing consumption" href="/meterbeheer/verbruik-factureren" description="Invoicing step by step" />
  <Card title="Invoices" href="/facturen" description="Draft invoices and invoicing" />
  <Card title="Customer management" href="/klantenbeheer" />
</Cards>


# Overview (/en-GB/meterbeheer)

With meter management you read your park's meters remotely and see who uses what, without anyone having to visit the meter cabinets. You see the meter readings, the consumption per period and the alarms, and you settle the consumption with the customer who is on the terrain at that moment. You find your meters under <UIPath>Park > Meters</UIPath>.

<DocScreenshot src="/screenshots/park/meters-list.png" alt="Park > Meters with all meters of the park" />

## How does this fit together? [#hoe-hangt-dit-samen]

A meter never belongs directly to a customer. The meter is attached to a **terrain**, and the customer is attached to that terrain through an **occupation**. Whoever has an occupation on the terrain now gets the consumption of the meters on that terrain.

```mermaid
flowchart LR
  M[Meter] -->|you link it to| T[Terrain]
  K[Customer] -->|gets an occupation on| T
  T --> V[Customer's consumption]
  V --> F[Invoice]
```

This has three consequences that often surprise people:

- There is no button to link a meter to a customer. You do it in two steps: meter to terrain, customer to terrain. See [Linking a meter to a customer](/meterbeheer/meter-koppelen).
- If a customer moves, you do not move the meter. The occupation ends and the next customer gets the consumption from their own start reading.
- If there is no occupation on the terrain, the consumption belongs to nobody and you cannot invoice it either.

<Callout type="info" title="Good to know">
- A terrain has at most one active occupation at a time. A terrain with an occupation is not in the list of choices for **Create occupation**.
- Meters on a shared LoRa network send a reading about twice a day. See the box below.
- Tillor reports a possible fault to the receiver (the gateway) if all your recently active LoRa meters sent nothing for more than 24 hours, and only with at least two active meters.
- If you want to invoice a customer's consumption and the outstanding amount is below the minimum amount, Tillor waits until the next invoice day.
- With automatic invoicing, Tillor holds back an invoice if the electricity or water consumption is at least double what the customer usually uses.
- A deleted meter cannot be recovered, along with all its meter readings and consumption periods.
</Callout>

<Callout type="info" title="For the technical reader">
LoRa is a wireless connection with a long range and low power consumption. The meter sends its reading to a receiver on or near your park, the gateway, which forwards it to Tillor. The Dev EUI is the unique number of a LoRa meter, 16 characters long (digits 0-9 and letters a-f). You enter that number when you create the meter. You recognise ICY meters by their serial number.
</Callout>

## What do you want to do? [#wat-wil-je-doen]

<Cards>
  <Card title="Link a meter to a customer" href="/meterbeheer/meter-koppelen" description="Meter to terrain, customer to terrain" />
  <Card title="View meter readings and trends" href="/meterbeheer/meterstanden-en-trends" description="Reading, consumption per day or hour, comparison with last week" />
  <Card title="Invoice consumption" href="/meterbeheer/verbruik-factureren" description="Manually or automatically, with a minimum amount" />
  <Card title="Alarms and meter status" href="/meterbeheer/alarmen-en-status" description="No reading, battery, signal and faults" />
  <Card title="Delete a meter" href="/meterbeheer/meter-verwijderen" description="In three steps, cannot be undone" />
  <Card title="Consumption batches" href="/meterbeheer/consumptie-batches" description="How consumption periods run, close and merge" />
</Cards>

## How do the meter readings come in? [#hoe-komen-de-meterstanden-binnen]

Smart meters send their reading themselves, usually daily or weekly. You do not have to do anything: new readings appear automatically on the meter and for the customer who is on the terrain. If a meter is not on a smart connection, you enter the reading yourself.

## Terms [#begrippen]

- **Meter**: a water, gas or electricity meter. See [Terms](/begrippen#meter).
- **Terrain**: the place where the meter is installed and where a customer stays. See [Terms](/begrippen#terrein).
- **Occupation**: a customer on a terrain for a period. See [Terms](/begrippen#bezetting).
- **Consumption period** (consumption batch): the consumption of one customer on one meter, from a start reading to an end reading.
- **Outstanding consumption**: consumption that has not yet been invoiced.
- **Start reading**: the meter reading with which a customer begins their occupation.


# Linking a meter to a customer (/en-GB/meterbeheer/meter-koppelen)

You do not link a meter to the customer itself. You attach the meter to a terrain and give the customer an occupation on that terrain. After that the consumption flows to the customer automatically. See [How does this fit together?](/meterbeheer#hoe-hangt-dit-samen) for the picture.

<Requires permission="Edit meters" />

Before you start:

- The meter is already in <UIPath>Park > Meters</UIPath>. A meter that is already attached to a terrain does not show up in the list of choices.
- The terrain exists and has no active occupation yet. If the terrain is occupied, it is not in the list of choices for **Create occupation**; if it says **No available terrains found.**, they are all occupied.
- The customer exists.

## Step 1: attach the meter to the terrain [#stap-1-de-meter-aan-het-terrein-hangen]

<Steps>
<Step>
### Open the terrain [#open-het-terrein]
Go to <UIPath>Park > Terrains</UIPath> and click the terrain.
</Step>
<Step>
### Click Add meter [#klik-op-meter-toevoegen]
At the bottom of the **Meters** card is **Add meter**. Choose the meter from the list.
</Step>
<Step>
### Confirm with Assign meter [#bevestig-met-meter-toekennen]
The meter is now in the **Meters** card of the terrain.
</Step>
</Steps>

<DocScreenshot src="/screenshots/park/terrain-detail.png" alt="Terrain details with the Meters card" />

## Step 2: put the customer on the terrain [#stap-2-de-klant-op-het-terrein-zetten]

<Steps>
<Step>
### Open the customer [#open-de-klant]
Go to <UIPath>Customers > Overview</UIPath> and open the customer. On the **Overview** tab you find the **Occupations** card.
</Step>
<Step>
### Click Create occupation [#klik-op-bezetting-aanmaken]
Choose the terrain. If there are meters on the terrain, you can enter a **start reading** for each meter. You choose an existing reading for that or type a value. If there are no meters, you see **No meters linked**.
</Step>
<Step>
### Confirm [#bevestig]
Click **Create occupation** again.
</Step>
</Steps>

## Unlinking a meter [#een-meter-loskoppelen]

Open the terrain, go to the **Meters** card and in the menu (...) next to the meter choose **Unlink from terrain**. The meter remains and you can attach it to another terrain. This option is only on the terrain page, not in the meter's own menu.

## What happens next? [#wat-gebeurt-er-daarna]

- For every meter on the terrain, Tillor starts a consumption period for this customer, from the start reading. See [Consumption batches](/meterbeheer/consumptie-batches).
- New meter readings are added to that period. You see them at the customer in the **Readings** card and at the meter in the **Consumption** card.
- When the occupation ends, Tillor closes the period. After that you can invoice the consumption, see [Invoicing consumption](/meterbeheer/verbruik-factureren).
- If you later attach an extra meter to a terrain with a running occupation, a consumption period begins for that meter as soon as you enter a meter reading.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the meter in the Add meter list">
The list only shows meters without a terrain. If the meter is already attached to another terrain, go to that terrain and choose **Unlink from terrain**.
</Accordion>
<Accordion title="No available terrains found">
All terrains already have an active occupation. First end the occupation on the terrain you want to use, or create a new terrain.
</Accordion>
<Accordion title="Unlink from terrain is not in the meter's menu">
That option is only in the menu (...) on the terrain page, in the **Meters** card. Tillor reports **Could not unlink meter** if it did not work; try again then.
</Accordion>
<Accordion title="The customer does not see any consumption from the meter">
Check three things: is the meter attached to the terrain, does the customer have an active occupation on that terrain, and has a meter reading come in since the start? Without an occupation the consumption belongs to nobody.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Invoicing consumption" href="/meterbeheer/verbruik-factureren" />
  <Card title="Terrains" href="/terreinen" />
  <Card title="Occupations" href="/bezettingen" />
</Cards>


# Deleting a meter (/en-GB/meterbeheer/meter-verwijderen)

You delete a meter that no longer exists in three steps. This cannot be undone. If you only want to take the meter off a terrain, unlink it instead, see [Linking a meter to a customer](/meterbeheer/meter-koppelen#een-meter-loskoppelen).

<Requires permission="Edit meters" />

<Steps>
<Step>
### Open the action menu [#open-het-actiemenu]
Click the three dots next to the meter, in the list or on the meter page, and choose **Delete meter**.

<DocScreenshot src="/screenshots/meterbeheer/meter-actions-menu.png" alt="Action menu of a meter with Delete meter" />
</Step>
<Step>
### Step 1 of 3: Continue [#stap-1-van-3-doorgaan]
You read that the meter disappears for everyone in your organisation. Click **Continue**, or **Cancel** to stop.

<DocScreenshot src="/screenshots/meterbeheer/meter-delete-dialog.png" alt="Step 1 of deleting a meter" />
</Step>
<Step>
### Step 2 of 3: see what disappears [#stap-2-van-3-bekijk-wat-verdwijnt]
You see all meter readings with photos, the comments, alarms and deviations, and the number of consumption periods. Consumption periods that have not been invoiced yet are shown in red. If the meter is still attached to a terrain, that is shown as well. Click **Continue**.
</Step>
<Step>
### Step 3 of 3: type the name [#stap-3-van-3-typ-de-naam]
Type the name of the meter. Only then does **Delete permanently** become active.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The meter, its meter readings, photos, comments and alarms are gone, also for your colleagues.
- Consumption periods that had not been invoiced can no longer be invoiced. So invoice or mark them first, see [Invoicing consumption](/meterbeheer/verbruik-factureren).
- If you delete the meter on its own page, you go back to the list of meters afterwards.

## Problems? [#problemen]

<Accordions>
<Accordion title="The Delete permanently button is grey">
You have to retype the name of the meter exactly. Check capitals and spaces.
</Accordion>
<Accordion title="Tillor reports Could not delete meter">
The meter has not been deleted. Try again; if it keeps failing, contact support.
</Accordion>
<Accordion title="I do not see Delete meter in the menu">
You need the **Edit meters** permission. Ask your administrator for it.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Linking a meter to a customer" href="/meterbeheer/meter-koppelen" />
  <Card title="Invoicing consumption" href="/meterbeheer/verbruik-factureren" />
</Cards>


# Viewing meter readings and trends (/en-GB/meterbeheer/meterstanden-en-trends)

On a meter's page you see the latest reading, who is using the meter now and how consumption is developing. That way you quickly see whether a meter is doing what it should and whether something odd is going on. If you want to settle the consumption, go to [Invoicing consumption](/meterbeheer/verbruik-factureren).

## Opening a meter [#een-meter-openen]

<Steps>
<Step>
### Go to Park > Meters [#ga-naar-park--meters]
You see all meters with **Name**, **Type** (water, electricity or gas), **Provider**, **Module** (Campère or PRM, only for ICY meters), **Terrain** and the **Last reading** with date. Meters with an active alarm have a small triangle.
</Step>
<Step>
### Click the meter [#klik-op-de-meter]
At the top you see the meter's details and, among others, the cards **Information**, **Consumption**, **Consumption & trends**, the alarms and the activity.
</Step>
</Steps>

<DocScreenshot src="/screenshots/park/meter-detail.png" alt="Meter details with the Consumption card" />

What is where:

- **Information**: serial number, type, terrain, last measurement and, if the meter reports it, the battery level. For an ICY meter it also shows which **Module** is installed at the spot (Campère or PRM), via which **Controller** that module communicates (with the name of that controller's meter cabinet), the **Off time** that is set at ICY and, if ICY knows it, the **Module serial number**.
- **Customer** in the header: the customer with an active occupation on the meter's terrain. If it says **No customer**, the terrain is not occupied or the meter is not attached to anything.
- **Consumption**: per customer the outstanding and the settled consumption.
- **Activity**: below the **Consumption** card the timeline with the creation of the meter, changes and manually entered, changed or deleted meter readings. Changes that Tillor detects at ICY, such as a different serial number or a different off time of the module, are in there too.

## Reading consumption and trends [#verbruik-en-trends-lezen]

At the top of the **Consumption & trends** card you see the consumption of **This week** and **Last week**, the difference **vs last week** and the weekly average (**Avg / week**). If the meter does not have enough history yet, it says **Not enough history**.

<DocScreenshot src="/screenshots/meterbeheer/meter-consumption-trends.png" alt="Consumption & trends of a meter" />

Below the chart are the **Insights**: the forecast for the next 30 days, the total in the chosen period, a peak day, days without consumption and the trend. If consumption over the last 7 days is well above normal, it says **Elevated usage**, together with the weather of those days. See [Weather](/weer).

<Tabs items={["Per day or per hour", "Choosing a period"]}>
<Tab value="Per day or per hour">
With the buttons at the top right of the card you switch the **Bucket size** between **Per day** and **Per hour**, and the **Chart type** between area and bar. Per hour shows the hourly consumption as bars; an hour that is still running is marked **still running**.

- If you choose a period of two days or less, such as **Today** or **Yesterday**, the chart automatically shows bars per hour.
- For a longer period, **Per hour** shows the last 31 days.
</Tab>
<Tab value="Choosing a period">
Click the calendar button at the top right. On the left you choose a quick period: **Today**, **Yesterday**, **Last 7 days**, **Last month**, **Last 3 months** or **All**. On the right you choose a **Start date** and **End date** on the calendar and confirm with **Apply**. Clicking one day shows that single day. You can also adjust the start and end time.

<DocScreenshot src="/screenshots/meterbeheer/meter-period-picker.png" alt="Period picker with quick periods and calendar" />
</Tab>
</Tabs>

## Switchable meters [#schakelbare-meters]

For meters that you can switch on or off remotely, such as ICY, the history chart also shows the on/off state. A green line means the meter was on. A red line with dotted markings means off. If a reading has no on/off value, it counts as on.

For an ICY meter you choose in the action menu under **Amperage** how many amps the spot gets. You only see the values up to the maximum that is set at ICY for the module at that spot: if that is 16 A, then 20 A and 25 A are not in the list.

## What happens next? [#wat-gebeurt-er-daarna]

Nothing changes in your data: these are views only. The trends and the weather are updated as soon as new meter readings come in.

## Problems? [#problemen]

<Accordions>
<Accordion title="It says Not enough history">
The meter does not have enough days with measurements yet for a comparison with last week. Come back later.
</Accordion>
<Accordion title="The chart is empty and it says No consumption available">
There is no consumption for the chosen period. Choose a longer period, for example **All**.
</Accordion>
<Accordion title="The last reading is old">
Check [Alarms and meter status](/meterbeheer/alarmen-en-status) to see whether there is an alarm or a fault at the receiver.
</Accordion>
<Accordion title="The value I want is not in the list for Amperage">
Tillor does not offer a value above the maximum that is set at ICY for the module at that spot. If that maximum is wrong, contact ICY.
</Accordion>
<Accordion title="Customer says No customer">
There is no active occupation on the meter's terrain, or the meter is not attached to any terrain (**No terrain**). See [Linking a meter to a customer](/meterbeheer/meter-koppelen).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Alarms and meter status" href="/meterbeheer/alarmen-en-status" />
  <Card title="Weather" href="/weer" />
  <Card title="Invoicing consumption" href="/meterbeheer/verbruik-factureren" />
</Cards>


# Invoicing consumption (/en-GB/meterbeheer/verbruik-factureren)

A customer's consumption is ready to be invoiced as soon as there is a consumption period with consumption. You put it on an invoice with one button, or you let Tillor invoice automatically on a fixed day. How a period starts and closes is explained in [Consumption batches](/meterbeheer/consumptie-batches).

Before you start:

- The customer has or had an occupation on a terrain with meters. Without an occupation there is no consumption to invoice, see [Linking a meter to a customer](/meterbeheer/meter-koppelen).
- There is outstanding consumption. If you see **No meters with outstanding consumption found.**, there is nothing to invoice.

## Invoicing consumption [#verbruik-factureren]

<Tabs items={["From the customer", "From all customers", "Invoiced outside Tillor"]}>
<Tab value="From the customer">
<Steps>
<Step>
### Open the customer [#open-de-klant]
Go to <UIPath>Customers > Overview</UIPath>, open the customer and look at the **Readings** card. It shows the outstanding periods per meter.
</Step>
<Step>
### Click Invoice consumption [#klik-op-factureer-verbruik]
For each period, Tillor puts a main line with the amount on an invoice, with an info line below it showing the dates and meter readings. If there is already a suitable draft invoice, Tillor adds the lines to it.
</Step>
<Step>
### Choose which meters and which invoice yourself [#kies-zelf-welke-meters-en-welke-factuur]
Open the arrow next to the button and choose **Add with selection...**. In **Advanced Invoicing** you choose an existing draft invoice under **Invoice (optional)**, or leave it empty for a new invoice. Under **Select meters** you tick which meters to include.
</Step>
</Steps>
</Tab>
<Tab value="From all customers">
Go to <UIPath>Customers > Outstanding Consumption</UIPath>. You see the customers with consumption that still has to be invoiced, with the total amount per customer. By default only customers without automatic billing are shown here. Invoice straight from the row.

<DocScreenshot src="/screenshots/meterbeheer/outstanding-consumption.png" alt="Customers > Outstanding Consumption" />
</Tab>
<Tab value="Invoiced outside Tillor">
If you invoiced the consumption elsewhere, you mark it without an invoice:

1. Open the period in the **Readings** card (customer profile) or **Consumption** (<UIPath>Park > Meters</UIPath> > meter).
2. Click the warning icon next to the period.
3. Confirm with **Yes, mark as invoiced**.

<Callout type="warn" title="Please note">
Tillor does not create an invoice here. You can only put periods back that you marked this way, using the revert icon for the settled periods. A period that is attached to a real invoice is only released when you delete that invoice.
</Callout>
</Tab>
</Tabs>

## Invoicing automatically [#automatisch-factureren]

If automatic billing of utilities is switched on for a customer, Tillor creates the invoice itself on the chosen day and sends it. You set this on the customer profile.

Two rules determine whether that invoice is actually created:

- **Minimum amount.** If the outstanding amount is below it, Tillor waits until a later invoice day. The minimum for all customers is under **Settings > Invoicing** as **Minimum amount for automatic utility invoices**. On the customer profile you can set your own **Minimum amount** in the invoice settings, which takes precedence for that customer. If you leave both empty, every amount is invoiced.
- **Consumption well above the usual.** If the outstanding electricity or water consumption is at least double what the customer usually uses, Tillor does not create the invoice. You get an email at your organisation's support address and the invoice is held back until someone has checked it.

Tillor compares each type with itself: electricity with earlier electricity, water with earlier water. The usual consumption is the median of the latest invoices of that type. There is no fixed limit in m³ or kWh. If the customer has no earlier invoice for that type yet, the invoice is sent automatically.

If the meter reading turns out to be correct after checking, you invoice the consumption yourself via the customer profile or via **Customers > Outstanding Consumption**. Set the **Automatic billing** filter to **Has date** there to see the customers that were held back.

## What happens next? [#wat-gebeurt-er-daarna]

- The periods go from outstanding to settled. If the occupation is still active, Tillor immediately opens a new period from the end reading, so there is no gap.
- The lines are on a draft invoice. Book and send it like any other invoice, see [Invoices](/facturen).
- If you delete the draft invoice again, the consumption becomes available again. See [Deleting an invoice](/meterbeheer/consumptie-batches#factuur-verwijderen).

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor reports Error invoicing">
The consumption could not be put on the invoice. Try again. If it does not work with a chosen draft invoice, choose **Create new invoice**.
</Accordion>
<Accordion title="The automatic invoice was not created and I received an email">
The consumption was at least twice the usual. Check the meter reading and invoice yourself if everything is correct.
</Accordion>
<Accordion title="The customer is not in Outstanding Consumption">
By default the list only shows customers without automatic billing. Set the **Automatic billing** filter to **Has date** for the other customers. If the customer is still not there, there is no outstanding consumption.
</Accordion>
<Accordion title="There is nothing to invoice although the customer used water">
Check whether the customer has an active occupation on the terrain where the meter is installed, and whether a meter reading has come in after the start reading. A period without consumption produces no amount.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Consumption batches" href="/meterbeheer/consumptie-batches" />
  <Card title="Invoices" href="/facturen" />
  <Card title="Customer management" href="/klantenbeheer" />
</Cards>


# Overview (/en-GB/nfc)

An NFC tag is a card, wristband, key ring or sticker that a customer holds against a reader, like contactless payment. With it they take a shower, open a door or charge their car. On this page you see how a tag, a customer and a balance belong together. The steps to link a tag or top it up are in [Managing tags](/nfc/nfc-tags).

You find all tags of your organisation on the **Controllers** page, in the **NFC tags** card.

<DocScreenshot src="/screenshots/nfc/nfc-tags-list.png" alt="The NFC tags card on the Controllers page" />

<Callout type="info" title="Good to know">
- A tag appears in Tillor automatically as soon as it has been held against a reader for the first time. You do not create it yourself.
- A tag belongs to at most one customer and has the status **Active**, **Inactive** or **Blocked**.
- The balance is stored on the tag in euros. A balance change is always kept as a transaction and cannot be edited or deleted.
- A payment that still has to be written to the tag stays open for 2 minutes. After that it expires.
- A blocked tag no longer works at the readers.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

The tag itself knows nothing. Tillor remembers who has it, what the balance is and where it may go. The reader asks Tillor at the moment the customer holds the tag against it.

```mermaid
flowchart TD
  K[Customer] --> T[NFC tag]
  T --> G[Access groups<br/>where may the tag go?]
  T --> S[Balance<br/>how much credit is on it?]
  L[Reader at shower, door or charging point] -->|customer holds the tag against it| T
  L --> TR[Transaction<br/>amount, reason and reader]
  S --> TR
```

- Without a customer, the reader refuses the tag. The screen then says **Tag not linked**.
- Without the right access group, the reader refuses the tag with **No access**.
- Without enough balance, it says **Insufficient balance**. All screen messages are in [Screen messages](/controllers/troubleshooting/scherm).
- Every charge or top-up appears as a line in the [transactions](/nfc/nfc-transacties).
- A tag is also an access method. You add it to a customer under [Access control](/toegangscontrole#een-toegangsmethode-toevoegen).

## Sections [#onderdelen]

<Cards>
  <Card title="Managing tags" href="/nfc/nfc-tags" description="Link tags to customers and edit the balance" />
  <Card title="Transactions" href="/nfc/nfc-transacties" description="All usage and balance changes" />
  <Card title="Controllers" href="/controllers" description="The readers that customers hold their tag against" />
</Cards>

## Terms [#begrippen]

- **Tag**: the card, wristband, sticker or key ring.
- **UID**: the unique number of the tag.
- **Balance**: the credit on the tag.
- **Access group**: determines which readers a tag is valid for.
- **Transaction**: a charge or top-up of the balance.

More explanation is in the [glossary](/begrippen).


# Managing tags (/en-GB/nfc/nfc-tags)

An NFC tag is only usable once it is attached to a customer. Then that customer can shower, open a door or charge with it, and you can keep track of the balance. You do all the steps below on the customer profile. What happens at every scan is explained in [Transactions](/nfc/nfc-transacties).

Before you start:

- The tag must already be in Tillor. That happens automatically as soon as it has been held against a reader for the first time.
- The tag must not be attached to another customer yet. Otherwise it is not in the list.
- If there is no free tag, the list says **No available tags found**.

## Linking a tag to a customer [#een-tag-koppelen-aan-een-klant]

<Steps>
<Step>
### Open the NFC Tags tab [#open-het-tabblad-nfc-tags]
Go to <UIPath>Customers > customer > NFC Tags</UIPath>. You see all tags of this customer. Above the table you filter on **UID** and **Type** (**Card**, **Bracelet**, **Sticker** or **Key ring**).
</Step>
<Step>
### Choose the tag [#kies-de-tag]
Click **Select a card** and choose the tag. You can search in the list.
</Step>
<Step>
### Click Assign [#klik-op-toewijzen]
Tillor reports **Card assigned to customer** and the tag is in the table.
</Step>
</Steps>

In the table you see for each tag the **UID** (the icon shows the type), the **Status**, the **Balance**, when it was **Last used** and the **Access groups**.

## What can you do with a tag? [#wat-kun-je-met-een-tag-doen]

Open the action menu (three dots) next to the tag.

<DocScreenshot src="/screenshots/nfc/nfc-tag-actions-menu.png" alt="Action menu of an NFC tag" />

| Action | What it does |
|---|---|
| **Edit balance** | Adds an amount or sets the balance, see below. |
| **Block** / **Unblock** | Sets the status to **Blocked** or back again. |
| **Access groups** | Determines which access groups the tag is valid for. |
| **Send low balance notification** | Sends the customer a notification that the balance is low. |
| **Copy personal URL** | Copies the link to the tag's own page. |
| **Remove from customer** | Detaches the tag from the customer. |
| **View details** | Opens the detail page with transactions and activity. |

### Adjusting the balance [#het-saldo-aanpassen]

<Steps>
<Step>
### Choose Edit balance [#kies-saldo-bewerken]
Open the action menu and choose **Edit balance**.
</Step>
<Step>
### Choose how you change the balance [#kies-hoe-je-het-saldo-wijzigt]
<DocScreenshot src="/screenshots/nfc/nfc-tag-topup-dialog.png" alt="Edit balance dialog" />

Under **Option** choose **Add balance** (an amount on top) or **Set balance** (an exact amount). At the bottom you see the result, for example **Current: ... → New: ...**.
</Step>
<Step>
### Confirm [#bevestig]
Enter the amount and click **Add** or **Set**. The amount must be positive. Tillor reports **Balance updated** or **Balance set**.
</Step>
</Steps>

### Blocking a tag [#een-tag-blokkeren]

You block a lost or stolen tag via **Block**. The status becomes **Blocked** and the tag no longer works at the readers. With **Unblock** in the same menu you lift the block. The customer can also block their tag themselves on the personal page.

### Choosing access groups [#toegangsgroepen-kiezen]

Choose **Access groups** and tick the groups on or off. The change applies immediately. If you see **No access groups available**, no groups have been set up for your organisation yet.

## What happens next? [#wat-gebeurt-er-daarna]

- A linked tag appears in the table and at the customer. If the customer holds it against a reader, the reader asks Tillor whether that is allowed.
- Every balance change becomes a [transaction](/nfc/nfc-transacties), also when you adjust the balance manually. The reason is then **Manually adjusted**.
- Under **Activity** on the detail page you see before and after of every change (balance, block, customer link).
- With **Remove from customer** the tag remains. It is free to give to another customer again. The transactions are kept.
- Via **Copy personal URL** the customer gets their own page. There they can block their card and, if you have set up online payments, top up themselves. That produces an invoice for the customer.

## Problems? [#problemen]

<Accordions>
<Accordion title="The list of tags is empty">
Tillor says **No available tags found**. Only tags that do not belong to anyone are in it. Detach the tag from the other customer with **Remove from customer**, or hold a new tag against a reader so it appears in Tillor.
</Accordion>
<Accordion title="Tillor says: Update failed">
The balance or the access groups could not be saved. Try again. If that does not work, refresh the page and check whether the tag is still attached to the customer.
</Accordion>
<Accordion title="The customer is refused at the reader">
Read the reason on the controller's screen, see [Screen messages](/controllers/troubleshooting/scherm). Usually the tag is **Blocked**, is not attached to a customer, the right access group is not switched on or the balance is too low.
</Accordion>
<Accordion title="Tillor says: Amount must be positive">
The amount must be filled in and greater than zero. Otherwise Tillor reports **Amount is required**, **Invalid amount** or **Amount must be positive**.
</Accordion>
<Accordion title="The customer cannot top up themselves">
Topping up via the personal page only works if your organisation has set up online payments, and if the tag is attached to a customer. See [Payment processing](/betalingsverwerking).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Transactions" href="/nfc/nfc-transacties" description="View the transaction history" />
  <Card title="Access control" href="/toegangscontrole" description="Barriers and access methods" />
  <Card title="Customer management" href="/klantenbeheer" description="Manage customer profiles" />
</Cards>


# Transactions (/en-GB/nfc/nfc-transacties)

Every balance change on an NFC tag is recorded as a transaction, including a manual adjustment. That way you see exactly when and why the balance changed. Transactions cannot be edited or deleted.

## Viewing transactions [#transacties-bekijken]

<Steps>
<Step>
### Open the tag [#open-de-tag]
Go to <UIPath>Customers > customer > NFC Tags</UIPath>, open the action menu (three dots) next to the tag and choose **View details**.
</Step>
<Step>
### Look at Transactions [#kijk-bij-transacties]
The **Transactions** card is on the detail page. The newest is at the top. With more than five transactions you page at the bottom.

<DocScreenshot src="/screenshots/nfc/nfc-tag-detail.png" alt="Detail page of an NFC tag with transactions" />
</Step>
</Steps>

Above the table are filters for **Date**, **Status**, **Origin** and **Cancel reason**. By default **Pending** and **Committed** are on. If you also want to see cancelled and expired transactions, click **Clear filters**.

## Columns [#kolommen]

| Column | Meaning |
|---|---|
| **Amount** | The balance change. Positive when topping up, negative when used. |
| **Reason** | The cause, for example **Shower usage at** a controller, **POS charge**, **POS top-up**, **Manually adjusted** or **Added because invoice ... was paid**. |
| **Controller** | The controller that caused the transaction. If it says **System**, there was no controller: a manual change, the reception app or a paid invoice. |
| **Date** | Date and time. |
| **Status** | See below. |
| **Origin** | **Online** or **Offline**. |
| **Description**, **Cancel reason** | Extra explanation, and for a cancelled transaction the reason. |

## Statuses [#statussen]

| Status | Meaning |
|---|---|
| <Status tone="info">Pending</Status> | The charge is reserved and still has to be written to the tag. |
| <Status tone="success">Committed</Status> | The transaction is complete and the balance has been adjusted. |
| <Status tone="error">Cancelled</Status> | The transaction did not go through. The reason is in **Cancel reason**. |
| <Status>Expired</Status> | The tag was not held against the reader in time. A reservation stays open for 2 minutes. |

Possible cancel reasons are **Insufficient balance**, **Not authorised**, **Card write failed** and **Expired**.

## What happens next? [#wat-gebeurt-er-daarna]

- A pending transaction becomes <Status tone="success">Committed</Status> as soon as the tag has received the new balance. If that does not succeed within 2 minutes, it becomes <Status>Expired</Status> and the balance does not change.
- **Origin** says **Offline** if the transaction did not run live via Tillor.
- A receptionist can make the same charge or top-up in the Tillor app. The balance is then only updated in Tillor. That shows as **POS charge** or **POS top-up**, without a controller.

## Problems? [#problemen]

<Accordions>
<Accordion title="The balance does not match what the customer expects">
Open the transactions and look at the reason and the date of the latest lines. A line with **Manually adjusted** was entered by a colleague. If you see transactions on **Expired** or **Cancelled**, nothing was charged for them.
</Accordion>
<Accordion title="A transaction is on Pending and does not go away">
Wait until the 2 minutes have passed. The transaction then becomes <Status>Expired</Status>. Have the customer hold the tag against the reader again.
</Accordion>
<Accordion title="The Transactions card is empty">
The tag has not been used yet and the balance has not been adjusted. There is then nothing to show.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Managing tags" href="/nfc/nfc-tags" description="Link cards and edit the balance" />
  <Card title="Customer management" href="/klantenbeheer" description="View customer profiles" />
</Cards>


# Notifications (/en-GB/notificaties)

The notifications overview shows every message Tillor has sent to customers and colleagues, by email, SMS, post, WhatsApp or push. You can see at a glance which messages have arrived, which are still on their way and which have failed. Sending an invoice message yourself is covered in [Sending an invoice or reminder](/communicatie/e-mails).

You open the overview via <UIPath>Communication > Notifications</UIPath>.

<Callout type="info" title="Good to know">
- If a message stays stuck for more than 5 minutes without being handed on, Tillor automatically tries again
- If nothing has been sent after 2 days, Tillor sets the message to **Failed**. This also applies to an SMS that stays **Pending** for that long
- The **Recent Communications** list shows 50 messages per page by default
- A click on a link in an email or SMS only counts if it happens at least about a second and a half after sending. This way, mail programs that fetch links in advance are not counted as a click
- Invoice messages are not sent automatically when you book an invoice. You start the sending yourself
- A card with a new notification in Tillor disappears after a few seconds. The notification stays in the bell until you read it
- Notifications that are always sent cannot be switched off
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

A message starts with a trigger. Tillor then picks the channel and stores the result in the overview.

```mermaid
flowchart LR
  A[Jij klikt op Verstuur notificatie] --> D[Bericht]
  B[Er gebeurt iets, zoals een meteralarm] --> D
  C[Een automatisering stuurt een bericht] --> D
  D --> E{Voor wie?}
  E -- Klant --> F[E-mail, sms, post of WhatsApp]
  E -- Collega --> G[Push, e-mail of telefoon, naar zijn voorkeuren]
  F --> H[Notificaties: status per kanaal]
  G --> H
  G --> I[Bel in Tillor]
  H --> J[Ook zichtbaar bij de klant en op de factuur]
```

- **To a customer**, you usually pick the channel yourself, for example in the **Send notification** window on an invoice. An [automation](/begrippen#automatisering) can also send a message to a customer.
- **To a colleague**, that colleague decides how Tillor reaches them, per type of alert. See [In-app alerts](#meldingen-in-de-app).
- **The result** is shown here, and also on the customer and on the invoice the message belongs to. The **Origin** column takes you straight there.

## Viewing notifications [#notificaties-bekijken]

<DocScreenshot src="/screenshots/notificaties/notifications-overview.png" alt="Notifications overview with statistics and lists" />

At the top there are four statistics:

- **Total Notifications**: all sending attempts
- **Sent Notifications**: messages that have been delivered
- **Failed Notifications**: messages that could not be delivered
- **Bounced Notifications**: messages that bounced back, mostly emails

Below them are four lists: **Bounced Notifications**, **Pending Notifications** (still queued or on their way), **Recent Communications** (all statuses) and **Failed Notifications**. With the **Type** and **Channel** filters above each list you narrow down what you see. Which types exist is described in [Notification types](/communicatie/notificatietypes).

Each row shows:

| Column | What you see |
|---|---|
| **Type** | What kind of message it is, such as New Invoice or Meter or controller alarm |
| **Origin** | The invoice, customer or payment the message belongs to |
| **Channel** | Email, SMS, Post, WhatsApp or Push |
| **Status** | The delivery status |
| **Recipient** | The email address, phone number, postal address or the user |
| **Date** | When the sending attempt was created |

### Viewing delivery details [#leveringsdetails-bekijken]

Click the channel in a row to see exactly what was sent and what happened.

<DocScreenshot src="/screenshots/notificaties/notifications-delivery-detail.png" alt="Delivery details of the New Invoice email" />

The window shows the delivery status, any error message, the recipient (**To**), the sender address (**From**) and, for email, the **Subject**. You also see when the message was ready (**Created At**) and when it actually went out (**Sent At**). **Sent By** shows the user who started the sending, or **System** if it happened automatically. At the bottom you find the **Content** and any **Attachments**.

For email and WhatsApp you also see **Read At**, and the list shows an eye icon next to messages that have been read. For email and SMS, **Clicked At** appears if the customer clicked a link.

For post there are extra fields: **Carrier reference**, **Tracking status** and **Last tracking update** (the latest event from the postal service), **Postage** at the time of sending and, for a registered item, the **Registered** label with the extra costs and a note about how they are passed on.

<DocScreenshot src="/screenshots/notificaties/notifications-post-registered-detail.png" alt="Delivery details of a registered reminder sent by post" />

### Statuses [#statussen]

| Status | Meaning |
|---|---|
| <Status tone="info">Pending</Status> | The message is being processed or is in the queue |
| <Status tone="success">Sent</Status> | The message has been delivered |
| <Status tone="error">Failed</Status> | Delivery failed |
| <Status>Skipped</Status> | The message was not (or no longer) sent, for example because push was not available or because a letter was cancelled at the postal service |
| <Status tone="info">Delayed</Status> | The message is scheduled and goes out later |
| <Status tone="warning">Bounced</Status> | The message could not reach the email address or number |
| <Status tone="error">Complained</Status> | The recipient marked the message as spam |

A letter by post starts as **Pending**. As soon as the postal service confirms that the letter is on its way or delivered, it becomes **Sent**. Undeliverable post becomes **Failed**. A cancelled letter becomes **Skipped**. You will mostly find that row under **Recent Communications**.

## In-app alerts [#meldingen-in-de-app]

Everything Tillor sends to you as a colleague, such as an assigned task, a mention in a comment or a meter alarm, can also be found in Tillor itself. Each alert appears there once, even if it was sent by both email and push. You do not need to set anything up for this.

- **Bell**: at the top right of the bar and at the bottom left of the menu (**Notifications**) there is a bell with the number of unread alerts. Click it for your most recent alerts. With **Mark all as read** you update the list in one go
- **Viewing the email**: click an alert to open the email you received for it, with a button at the top to the related page (for example **Open task**). An alert without an email takes you straight to that page. The alert is then marked as read
- **Card at the bottom right**: if an alert comes in while you have Tillor open, it appears as a card at the bottom right, in the same place as an incoming conversation. Click the card or close it with the cross. A closed card stays unread in the bell. If you are already on the page the alert is about, you do not get a card
- **Stays visible**: alerts for which you are also called, such as a connector that can no longer be reached, stay until you close them
- **Inbox**: new messages in the inbox keep their own card and counter under **Inbox**. In the bell they are immediately marked as read. This also applies to the daily overview of meters that need attention
- **Per day**: the list shows your alerts per day, with the category next to them. With the buttons at the top you show one category

Alerts are personal: you only see your own, per organisation.

In an [automation](/begrippen#automatisering), at the **Notify colleagues** step, you use **Show in Tillor** to choose whether the alert gets a card and an unread counter. If that is switched off, it appears in the list as read.

### Switching off alerts [#meldingen-uitzetten]

<Steps>
<Step>
### Open your account [#open-je-account]
Click your name in the menu and choose **Account**.
</Step>
<Step>
### Go to Notifications [#ga-naar-meldingen]
Switch the channels on or off per type of alert. In the **All notifications** row you switch a channel off for everything at once.
</Step>
</Steps>

A channel you switch off under **All notifications** stays off for every alert below it, except the alerts that are always sent. A type for which you switch off all channels also no longer appears in the app. For a colleague you arrange this under <UIPath>Settings > Users</UIPath>, see [Setting up a colleague's alerts](/gebruikers/gebruikers-en-rechten#meldingen-van-een-collega-instellen).

## External notifications [#externe-notificaties]

A linked external system, for example your newsletter or booking software, can have emails it sent to a customer itself registered in Tillor. You find them on the customer, on the invoice and under **Recent Communications**, among the messages from Tillor. You recognise them by the **External** label with the name of the system.

- Tillor did not send the message and cannot check its status. The status comes from the external system
- External notifications do not count in the statistics at the top and do not appear in the **Bounced Notifications**, **Pending Notifications** and **Failed Notifications** lists
- In the detail window, images are blocked by default. This way the sender does not notice that you open the message. Click **Load images** to show them anyway
- The external system can later update or delete its own notifications. You can see this in the [activity log](/activiteitenlog) of the customer or invoice

Who may register external notifications is arranged with the permissions **Register external notifications** and **Manage other external notifications**. The technical explanation for integrators is under [Developers > External notifications](/ontwikkelaars/externe-notificaties).

## Problems? [#problemen]

<Accordions>
<Accordion title="A message is Bounced">
The customer's email address or number does not exist or cannot receive messages. Open the message via the **Bounced Notifications** list and read the error message. Go to the customer profile via the **Origin** column, correct the email address and send the message again with **Send notification** on the invoice.
</Accordion>
<Accordion title="An SMS or WhatsApp message failed">
Open the message via **Failed Notifications** and read the error message. Usually the phone number is wrong or is missing the country code. Correct the number on the customer profile and send again.
</Accordion>
<Accordion title="An SMS stays Pending">
The telephone operator sometimes reports delivery with a delay. After 2 days Tillor automatically sets the SMS to **Failed**. Open the detail window for the error message and check the number.
</Accordion>
<Accordion title="A letter by post failed or is undeliverable">
Open the message via **Pending Notifications** or **Failed Notifications**. Check the postal address on the customer profile (street, postcode and town) and send the letter again with **Send notification** or **Send reminder** on the invoice.
</Accordion>
<Accordion title="A letter is Skipped">
The letter was cancelled at the postal service. Find the shipment under **Recent Communications** and look at **Tracking status** to see what happened. Only send again if the customer still needs to receive the letter.
</Accordion>
<Accordion title="I do not see the Send notification button on an invoice">
The button only appears on a booked invoice, and only if the customer has an email address, a phone number or a complete postal address. Add one of these details on the customer profile.
</Accordion>
<Accordion title="I no longer receive an alert in Tillor">
Under **Account**, at **Notifications**, check whether you have switched off all channels for that type. A type without channels also no longer appears in the bell.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **[Notification](/begrippen#notificatie)**: a message that Tillor sends to a customer or colleague, by email, SMS, post, WhatsApp or push.
- **Channel**: the route a message takes. One notification can go through several channels.
- **Delivery**: one sending attempt via one channel, with its own status.
- **Bounced**: the message came back because the address or number does not exist.
- **Alert**: a notification for a [user](/begrippen#gebruiker) of Tillor, visible in the bell.
- **External**: a message that a linked system sent itself and that is only registered in Tillor.

More terms are in the [glossary](/begrippen).

## See also [#zie-ook]

<Cards>
  <Card title="Sending an invoice or reminder" href="/communicatie/e-mails" description="Send a message yourself from an invoice" />
  <Card title="Notification types" href="/communicatie/notificatietypes" description="All kinds of messages and when they go out" />
  <Card title="Sending an invoice" href="/facturen/versturen" description="Invoices and reminder letters by post" />
  <Card title="Automations" href="/automatiseringen" description="Have messages sent by an automation" />
</Cards>


# Comments (/en-GB/notities)

Comments let colleagues work together on customers, invoices, reservations and other records, without the customer seeing anything. You write a comment on the record's detail page, mention a colleague with an @ and pin important comments. Start at [Adding a comment](#een-opmerking-toevoegen).

<Callout type="info" title="Good to know">
- Comments are always internal. They never become visible to customers, not even on invoices or in emails.
- A colleague you mention with @ gets a notification.
- A resolved comment can no longer be edited or pinned.
- Resolving a comment automatically unpins a pinned comment.
- Deleting a comment cannot be undone.
- A pinned comment stays visible at the top of the record, so you do not have to scroll to the **Comments** card.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  R[Record: klant, factuur, reservering...] --> O[Opmerking]
  O -->|@ vermelding| M[Melding voor de collega]
  O -->|Vastzetten| P[Bovenaan het record]
  O -->|Herinnering| T[Taak om op te volgen]
  O -->|Oplossen| X[Opgelost en ingeklapt]
```

All comments of your organisation are also listed together under <UIPath>Communication > Comments</UIPath>, with a reference to the record they belong to.

## Where do you find comments? [#waar-vind-je-opmerkingen]

Detail pages have a **Comments** card. Depending on the record:

- <UIPath>Customers > Overview</UIPath> or <UIPath>Customers > Communication</UIPath>: on the customer profile
- <UIPath>Administration > Invoices</UIPath>: on the invoice detail page
- <UIPath>Customers > Reservations</UIPath>: on the reservation detail page
- <UIPath>Park > Terrains</UIPath>: on the terrain detail page
- <UIPath>Park > Meters</UIPath>: on the meter detail page
- <UIPath>Administration > Payment Reports</UIPath>: on the payment report

## Adding a comment [#een-opmerking-toevoegen]

<Steps>
<Step>
### Open the record [#open-het-record]
Open a customer profile or an invoice, for example, and go to the **Comments** card.

<DocScreenshot src="/screenshots/notities/invoice-comments.png" alt="Comments card on the invoice detail page" />
</Step>
<Step>
### Click Add comment [#klik-op-reactie-toevoegen]
Type your comment in the **Write a comment...** text box.

- Type **@** and choose a colleague from the list to mention that person. They get a notification.
- Type **/** to link a customer, invoice, meter, terrain or other record.
- Add an attachment via **Attach file**, by pasting or by dragging files in.
</Step>
<Step>
### Click Submit [#klik-op-verzenden]
Your comment is now on the card. With **Reply** on an existing comment you start a discussion thread.
</Step>
</Steps>

### What happens next? [#wat-gebeurt-er-daarna]

- The comment appears on the record and in the central overview.
- A mentioned colleague gets a notification.
- If you want to be sure someone responds, click the little clock on the comment (**Set a reminder to follow up**). Tillor then creates a task, so you can check later whether it was picked up.

## Managing comments [#opmerkingen-beheren]

Each comment has action buttons at the top right, as far as you have the permissions.

### Editing or deleting a comment [#opmerking-bewerken-of-verwijderen]

- **Edit**: change the text. This works on your own comments, and not on resolved comments.
- **Delete**: delete the comment, after confirmation. This cannot be undone.

### Pinning a comment [#opmerking-vastzetten]

Do you want to keep an important comment visible at the top?

1. Click the pin icon (**Pin**).
2. The comment gets the **Pinned** label and appears at the top of the list.
3. Click the pin icon again to unpin it (**Unpin**).

Resolved comments cannot be pinned.

#### Where does a pinned comment appear [#waar-staat-een-vastgezette-opmerking]

- On a customer profile, it appears directly below the customer details at the top, above the tabs.
- On an invoice, reservation, terrain or meter, it appears in the **At a glance** card at the top, together with the open tasks. That card collapses when it has nothing in it.

### Marking a comment as resolved [#opmerking-als-opgelost-markeren]

For discussions that have been wrapped up:

1. Click the tick (**Resolve**).
2. The comment is marked as **Resolved** and disappears from the open list.
3. On a detail page, resolved comments appear at the bottom in a collapsible section.
4. Click the tick again to undo this (**Unresolve**).

### Downloading comments as a PDF [#opmerkingen-als-pdf-downloaden]

With the print icon you download all comments of a record as a PDF (**Download all comments as PDF**), or a single discussion (**Download this comment thread as PDF**).

## Overview of all comments [#overzicht-van-alle-opmerkingen]

Go to <UIPath>Communication > Comments</UIPath> for a central overview. At the top you see statistics (total, open, resolved and pinned). Below that:

<DocScreenshot src="/screenshots/notities/comments-overview.png" alt="Central comments overview - Open comments" />

- **Open comments**: comments that are still open.
- **Resolved comments**: closed comments for reference.

Each comment shows the **Origin** (for example customer or invoice), so you can go straight to the record.

### Filtering [#filteren]

- **Last week**, **Last month** or **All**: filter by creation date.
- **Show mentions only**: only comments in which you are mentioned.
- Search with **Search comments...**, or filter by author, mentioned user, resolved, pinned and main comment or reply.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says: Comment not created">
Your comment was not saved. Check that the text box is not empty and try **Submit** again.
</Accordion>
<Accordion title="I do not see a colleague when typing @">
If it says **No users found**, try another name or an email address. Only users of your organisation appear in the list.
</Accordion>
<Accordion title="I cannot edit or pin a comment">
A resolved comment is locked. First click the tick to reopen it (**Unresolve**). Editing is only possible on your own comments.
</Accordion>
<Accordion title="The pinned comment has disappeared">
Resolving a comment unpins it. Reopen it with the tick and then pin it again.
</Accordion>
<Accordion title="Tillor says: Failed to pin/unpin comment or Failed to resolve/unresolve comment">
The change was not applied. Reload the page and try again.
</Accordion>
<Accordion title="Tillor says: Could not create PDF">
Try again. If the PDF does not appear, your browser is blocking a pop-up. Allow pop-ups for this site.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Comment**: an internal text on a record, with optional attachments. See [comment](/begrippen#opmerking).
- **Mention**: a colleague you name with @. They get a notification.
- **Pin**: keep a comment at the top of the record.
- **Resolved**: a completed comment that disappears from the open list.
- **Origin**: the record a comment belongs to.
- **Task**: a to-do that can result from a reminder on a comment. See [task](/begrippen#taak).

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" description="Manage customer profiles" />
  <Card title="Invoices" href="/facturen" description="Manage invoices" />
</Cards>


# Park (/en-GB/park)

Under **Park** you find everything that belongs to the physical location: the map with today's occupancy, the list of terrains, the meters and meter cabinets, and the weather. Start with the [Terrains](/terreinen), because an occupancy, a meter and a rate all hang off them.

## What is where? [#wat-vind-je-waar]

| Menu | Purpose | Guide |
|---|---|---|
| <UIPath>Park > Map</UIPath> | The map of your park, coloured by occupancy per day | [Map](/kaart) |
| <UIPath>Park > Terrains</UIPath> | All terrains, their rate and the meters on them | [Terrains](/terreinen) |
| <UIPath>Park > Meters</UIPath> | All water, gas and electricity meters | [Meter management](/meterbeheer) |
| <UIPath>Park > Meter Cabinets</UIPath> | The cabinets that hold meters and which meters are in them | Manage your meter cabinets and their assigned meters |
| <UIPath>Park > Weather</UIPath> | The weather per day at the location of your park | [Weather](/weer) |

<DocScreenshot src="/screenshots/park/map-overview.png" alt="Map of the park with coloured terrains" />

## Meter cabinets [#meterkasten]

Under <UIPath>Park > Meter Cabinets</UIPath> you manage the meter cabinets and the meters assigned to them. With **New Meter Cabinet** you add a cabinet, with a name and a description.

## How does this fit together? [#hoe-hangt-dit-samen]

The **terrain** is the anchor point. You attach meters to a terrain. A customer ends up on a terrain through an **occupancy**, and a guest for a short stay through a **reservation**. The consumption of the meters on the terrain goes to the customer with the active occupancy.

```mermaid
flowchart LR
  M[Meters] --> T[Terrein]
  T --> K[Plattegrond]
  B[Bezetting<br/>klant voor langere tijd] --> T
  R[Reservering<br/>verblijf met in- en uitcheckdatum] --> T
  T --> V[Tarief en verbruik op de factuur]
```

A terrain only gets a colour on the map once you have drawn its boundary. See [Drawing terrain boundaries](/kaart#terreingrenzen-intekenen).

<Callout type="info" title="Good to know">
- A terrain has at most one active occupancy at a time.
- A new terrain is not bookable by default. Tick **Bookable** if customers may reserve it online.
- You cannot type in the surface area. Tillor calculates it as soon as you draw the terrain on the map, and uses it for the rate.
- The map always opens on today. Your other map settings (style, labels, layers) are remembered.
- The labels with nights and departure only appear from zoom level 17.5.
- The weather is fetched every night for the map centre of your organisation.
</Callout>

## Terms [#begrippen]

- **Terrain**: a place in your park with a name, a rate and possibly meters. See [Terms](/begrippen#terrein).
- **Map**: the interactive map under Park.
- **Meter cabinet**: a cabinet with meters. See [Terms](/begrippen#meterkast).
- **Occupancy**: a customer on a terrain for a period. See [Terms](/begrippen#bezetting).
- **Bookable**: a terrain that customers may reserve online.

## See also [#zie-ook]

<Cards>
  <Card title="Terrains" href="/terreinen" description="Create terrains, rate and meters" />
  <Card title="Map" href="/kaart" description="Map, layers and terrain boundaries" />
  <Card title="Meter management" href="/meterbeheer" />
  <Card title="Weather" href="/weer" />
</Cards>


# Print settings (/en-GB/printer/afdrukinstellingen)

This is the list of all settings under <UIPath>Settings > Printing</UIPath>. The settings apply to your whole organisation. Step-by-step setup is in [Setting up printers](/printer/printers-instellen).

<DocScreenshot src="/screenshots/printer/settings-dialog-printers.png" alt="Settings > Printing" />

| Setting | Meaning |
| ---------- | --------- |
| **PDF printing** | Turns on printing of invoices and documents to physical printers. Without it, Tillor prints nothing. |
| **Auto-print invoice on payment** | Paid invoices automatically go to the print queue. Per payment type you choose whether that happens immediately, at the next cutoff time or not at all. |
| **Auto-print ID document on link** | When you link an identity scan to a customer or contact (also when creating a customer from a scan), the summary goes to the A4 printer as a PDF. Requires: **PDF printing** switched on and a filled-in **PDF printer IP**. |
| **PDF printer IP** | Network address of the A4 printer for invoices and documents, for example `192.168.1.100`. |
| **Thermal printer IP** | Network address of the receipt printer, for example `192.168.1.101`. |
| **Receipt paper width** | Width of the receipt roll: **80 mm** (default) or **58 mm**. Tillor adjusts the line length and the logo on the receipt to this. |
| **Label printer IP** | Network address of the label printer, for example `192.168.1.102`. |
| **Print cutoff schedule** | One or more times per weekday, to the minute, for example 09:00 and 13:30. Empty means there are no cutoff times that day. |
| **Auto-print timing by payment type** | Per channel (terminal/counter, manual, online, mandate, transfer): **Print immediately**, **Next cutoff time** or **Do not auto-print**. By default, terminal and manual print immediately. Online, mandate and transfer wait for the cutoff time. |
| **Pause printing until** | Holds the print queue until the chosen moment. **Clear pause** removes the pause. You can also pause from the [print queue](/printer/printwachtrij). |

Click **Save settings** at the bottom to apply your changes. They take effect immediately.

<Callout type="info">
Printers must be on the same network as the connector and have a fixed IP address. Give the printer a fixed address in your router, otherwise the address may change.
</Callout>

## See also [#zie-ook]

<Cards>
  <Card title="Setting up printers" href="/printer/printers-instellen" description="The steps to get started" />
  <Card title="Printing documents" href="/printer/documenten-afdrukken" description="Print an invoice or receipt" />
  <Card title="Connector" href="/connector" description="The program that controls the printer" />
</Cards>


# Printing an invoice or receipt (/en-GB/printer/documenten-afdrukken)

You print an invoice from the invoice page, on the A4 printer or on the receipt printer. For payments, Tillor can also print receipts by itself. You can also show an invoice on the tablet without printing.

<Requires permission="Edit settings" />

Before you start:

- The printers are set up, see [Setting up printers](/printer/printers-instellen).
- A connector is active for your organisation. Without one, the options **Send to A4 printer** and **Send to receipt printer** do not appear in the menu.

## Printing an invoice [#een-factuur-afdrukken]

<Steps>
<Step>
### Open the invoice [#open-de-factuur]
Go to <UIPath>Administration > Invoices</UIPath> and open the invoice.
</Step>
<Step>
### Choose how to print [#kies-hoe-je-afdrukt]
<Tabs items={["Op papier via de browser", "Naar een printer in het netwerk"]}>
<Tab value="Op papier via de browser">
Click **Print**. Your browser opens its own print window.
</Tab>
<Tab value="Naar een printer in het netwerk">
Click the arrow next to **Print** and choose **Send to A4 printer** or **Send to receipt printer**. Tillor puts a job in the print queue.
</Tab>
</Tabs>

<DocScreenshot src="/screenshots/facturen/invoice-booked-actions.png" alt="Invoice detail - print and payment actions" />
</Step>
</Steps>

## Receipts after a payment [#bonnen-na-een-betaling]

In <UIPath>Settings > Printing</UIPath>, switch on **Auto-print invoice on payment**. Paid invoices then go to the A4 printer and optionally the receipt printer, immediately or at the next cutoff time, depending on the payment channel.

Per product you can also switch on **Thermal print** and **A4 print** and set the number of copies on the product page. Those copies come out in addition as soon as that product is on a paid invoice.

## Showing an invoice on the tablet [#een-factuur-op-de-tablet-tonen]

Do you want to show an invoice without printing it? In the menu with the three dots on the invoice, choose **Preview on iPad**, or click **Preview on iPad** in the payment window of a cash payment. The PDF appears on the linked tablet and Tillor reports **PDF sent to iPad**. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken).

## What happens next? [#wat-gebeurt-er-daarna]

- A job for a printer appears in the [print queue](/printer/printwachtrij) with a status. At the print time it goes to the printer.
- If printing fails, Tillor in most cases tries again automatically. After that the job stays on **Failed** until you retry or cancel it.
- The invoice itself does not change: printing does not book or send anything.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Send to A4 printer">
There is no active connector for your organisation, or **PDF printing** is switched off. See [Setting up printers](/printer/printers-instellen).
</Accordion>
<Accordion title="Tillor says Printing failed">
The message is **Failed to send the document to the printer.** Open the [print queue](/printer/printwachtrij) for the reason under **Last error**, for example a printer that is offline or out of paper.
</Accordion>
<Accordion title="Tillor says Download failed">
The PDF could not be downloaded. Try again.
</Accordion>
<Accordion title="Tillor says PDF not sent">
The PDF could not reach the tablet. This means no tablet is reachable. Open the Tillor app on the tablet and check whether it is **Connected** under <UIPath>Settings > Tablets & kiosks</UIPath>.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Managing the print queue" href="/printer/printwachtrij" description="Follow jobs and retry them" />
  <Card title="Invoices" href="/facturen" description="Manage and send invoices" />
  <Card title="Products" href="/producten" description="Set copies per product" />
</Cards>


# Overview (/en-GB/printer)

With the printer link you print invoices, receipts and labels directly from Tillor on a printer at your park, without downloading the document first. You set up the printers once under [Setting up printers](/printer/printers-instellen) and after that you print with a click or let Tillor do it on a payment.

## How does this fit together? [#hoe-hangt-dit-samen]

Tillor does not send a print job straight to your printer. The job first goes into the print queue. At the print time Tillor hands it to the connector, a small program on a computer in your network, and that makes the printer print.

```mermaid
flowchart LR
  A[Je print een factuur of<br/>een betaling komt binnen] --> B[Printwachtrij in Tillor]
  B -- meteen of op het afdrukmoment --> C[Connector in je netwerk]
  C --> D[Printer]
  B -- mislukt --> E[Tillor probeert opnieuw]
```

That is why the connector must be online and the printer reachable on the same network. Without an active connector you do not see the options to send to a printer. See [Connector](/connector).

<Callout type="info" title="Good to know">
- There are three kinds of printers: an A4 printer for invoices and documents, a thermal printer for till receipts and a label printer.
- The width of the receipt roll is 80 mm (default) or 58 mm.
- A failed job is retried automatically by Tillor after 10 seconds, 5 minutes and 15 minutes. After that it is set to **Failed**. If the paper has run out or the printer is offline, it is set to **Failed** immediately.
- Every Monday morning Tillor retries all jobs that are on **Failed** one more time.
- Printing can be paused for 15 minutes, 1 hour, 4 hours, 6 hours, 1 day or until you resume it yourself.
- By default, terminal payments and manual payments print immediately. Online payments, mandates and transfers wait for the next print time.
</Callout>

## What do you want to do? [#wat-wil-je-doen]

<Cards>
  <Card title="Setting up printers" href="/printer/printers-instellen" description="Enter network addresses and choose print times" />
  <Card title="Printing documents" href="/printer/documenten-afdrukken" description="Print an invoice or receipts after payment" />
  <Card title="Managing the print queue" href="/printer/printwachtrij" description="Pause, retry or cancel jobs" />
  <Card title="Print settings" href="/printer/afdrukinstellingen" description="All settings at a glance" />
</Cards>

## Terms [#begrippen]

- **Print queue**: the list of print jobs that Tillor still has to send.
- **Print time**: a fixed time on a weekday at which Tillor sends bundled jobs, also called the cutoff time.
- **Thermal printer**: the printer for till receipts.
- **Connector**: the program in your network that controls the printer. See [Connector](/connector).
- **IP address**: the network address of a printer, for example `192.168.1.100`.

More explanation is in the [glossary](/begrippen).


# Setting up printers (/en-GB/printer/printers-instellen)

Before Tillor can print, it needs to know which printers you have and where they are in your network. You set this up once for your whole organisation. After that you can [print documents](/printer/documenten-afdrukken). Every setting with an explanation is in [Print settings](/printer/afdrukinstellingen).

<Requires permission="Edit settings" />

Before you start:

- The connector runs on a computer in the same network as the printers. See [Connector](/connector). If it is not active, you will not see any options to send to a printer later.
- You know the IP address of each printer, which is the network address, for example `192.168.1.100`. Give the printer a fixed address in your router, otherwise the address may change and printing stops.

## Adding a printer [#een-printer-toevoegen]

<Steps>
<Step>
### Open Printing [#open-afdrukken]
Go to <UIPath>Settings > Printing</UIPath>.

<DocScreenshot src="/screenshots/printer/settings-dialog-printers.png" alt="Settings > Printing" />
</Step>
<Step>
### Switch on PDF printing [#zet-pdf-afdrukken-aan]
Without this switch Tillor prints nothing.
</Step>
<Step>
### Enter the printer addresses [#vul-de-printeradressen-in]
Under **Printer IP addresses**, enter the address of the **PDF printer IP** (A4), the **Thermal printer IP** (receipts) and the **Label printer IP**. Leave empty what you do not have. At **Receipt paper width**, choose 80 mm or 58 mm, to match your receipt roll.
</Step>
<Step>
### Choose when to print [#kies-wanneer-er-afgedrukt-wordt]
At **Print cutoff schedule**, set one or more times per weekday (for example 09:00 and 13:30). At **Auto-print timing by payment type**, choose for each payment channel: **Print immediately**, **Next cutoff time** or **Do not auto-print**.
</Step>
<Step>
### Click Save settings [#klik-op-instellingen-opslaan]
The settings apply immediately to your whole organisation.
</Step>
</Steps>

## Automatic printing on payment [#automatisch-afdrukken-bij-betaling]

If you want a paid invoice to come out on paper without any action, switch on **Auto-print invoice on payment**. Per payment channel you decide with the print timing above whether that happens immediately or at the next cutoff time.

## What happens next? [#wat-gebeurt-er-daarna]

- For every print, Tillor puts a job in the [print queue](/printer/printwachtrij), which the connector passes on to the printer.
- Paid invoices automatically go to the A4 printer, and optionally the receipt printer, if you have switched that on.
- If you choose a cutoff time for a channel, Tillor bundles the jobs until that moment. If there is no print time that day, there is no cutoff time.
- Try it out with an invoice, see [Printing documents](/printer/documenten-afdrukken).

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Send to A4 printer on an invoice">
The options only appear if **PDF printing** is switched on and a connector is active for your organisation. Check both.
</Accordion>
<Accordion title="Tillor says The printer is offline or not responding">
The printer is off, has no network connection or the IP address is no longer correct. Check the address under <UIPath>Settings > Printing</UIPath> and whether the connector is online.
</Accordion>
<Accordion title="Tillor says Paper, toner or ink is empty">
Refill the printer and retry the job from the print queue.
</Accordion>
<Accordion title="Tillor says The printer did not respond in time">
The connector got no answer from the printer. Check that the connector is running and the printer is reachable. Look in the print queue to see whether the job was retried.
</Accordion>
<Accordion title="Receipts do not come out immediately">
Check at **Auto-print timing by payment type** whether that channel is set to **Next cutoff time**. The receipt then waits until the time you chose at **Print cutoff schedule**. If you have paused printing, look in the [print queue](/printer/printwachtrij).
</Accordion>
<Accordion title="The receipt does not fit on the paper">
Check the **Receipt paper width**: 80 mm or 58 mm.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Print settings" href="/printer/afdrukinstellingen" description="All settings at a glance" />
  <Card title="Connector" href="/connector" description="The program that controls the printer" />
  <Card title="Managing the print queue" href="/printer/printwachtrij" description="Pause or retry jobs" />
</Cards>


# Managing the print queue (/en-GB/printer/printwachtrij)

In the print queue you see which print jobs are waiting, in progress or failed. Here you pause printing, push jobs through and sort out jobs that did not succeed. The list refreshes automatically as soon as a job changes status.

<Requires permission="Edit settings" />

Before you start: the printers are set up, see [Setting up printers](/printer/printers-instellen).

## Viewing the queue [#de-wachtrij-bekijken]

Go to <UIPath>Administration > Print queue</UIPath>. The lists are:

- **Queued, scheduled, and processing**: jobs that are still being processed. A job with the status **Scheduled for later** waits for its **Scheduled** time and is then printed automatically, unless printing is paused.
- **Failed**: jobs that have definitively failed, with the reason under **Last error**.
- **All print jobs**.

## Pausing printing [#het-afdrukken-pauzeren]

<Steps>
<Step>
### Choose Pause printing [#kies-afdrukken-pauzeren]
Click **Pause printing** and choose a duration: 15 minutes, 1 hour, 4 hours, 6 hours, 1 day, or **Until we re-enable**.

<DocScreenshot src="/screenshots/printer/print-pause-menu.png" alt="Menu with the duration of the pause" />
</Step>
<Step>
### Resume when you are ready [#hervat-wanneer-je-klaar-bent]
Click **Resume printing**. Otherwise it resumes automatically after the chosen duration.
</Step>
</Steps>

During the pause, both immediate and scheduled jobs wait. New jobs stay in the queue. Next to the pause icon it shows until when it lasts. You can also set the pause at **Pause printing until** in <UIPath>Settings > Printing</UIPath>.

## Pushing jobs through or recovering them [#opdrachten-doorzetten-of-herstellen]

<Tabs items={["Opdrachten blijven hangen", "Een opdracht is mislukt"]}>
<Tab value="Opdrachten blijven hangen">
Click **Process queue** in the toolbar of the list. Scheduled jobs are then processed immediately. The button is greyed out while printing is paused, with the tip **Resume printing to process the queue**.
</Tab>
<Tab value="Een opdracht is mislukt">
Open the menu with the three dots on the row and choose **Retry** to send it again, or **Cancel**. A cancelled job gets the status **Cancelled** and is no longer printed.
</Tab>
</Tabs>

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor retries a failed job by itself after 10 seconds, then after 5 minutes and then after 15 minutes. If it still does not work, it is set to **Failed**.
- Errors that a new attempt does not solve are not retried by Tillor: paper, toner or ink empty, a printer that is offline or paused, or a disabled printer queue. Those are set to **Failed** immediately.
- Every Monday morning Tillor queues all jobs that are on **Failed** one more time.
- A job that stays on **Failed** does nothing until you retry or cancel it.

## Problems? [#problemen]

<Accordions>
<Accordion title="The job is Failed with The printer is offline or not responding">
Switch the printer on, check the network connection and whether the connector is online. Then choose **Retry**.
</Accordion>
<Accordion title="The job says Paper, toner or ink is empty">
Refill the printer and choose **Retry**.
</Accordion>
<Accordion title="The job says Printing is paused. Check paper, toner or ink.">
The printer itself is paused, for example because of a paper jam. Fix that at the printer and try again.
</Accordion>
<Accordion title="The job says The print job was lost or did not finish on the printer">
The job was sent to the printer but not completed. Check whether anything has come out before you retry, otherwise you will get a duplicate.
</Accordion>
<Accordion title="The job says The printer queue is disabled">
The queue on the printer itself is off. Switch it on at the printer and try again.
</Accordion>
<Accordion title="Process queue is greyed out">
Printing is paused. Choose **Resume printing**.
</Accordion>
<Accordion title="Tillor says Could not start print queue processing">
The queue could not be processed. Try again. If that does not work, check whether the connector is online.
</Accordion>
<Accordion title="Tillor says Could not retry print job">
Try again, or cancel the job and print the document again from the invoice.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Setting up printers" href="/printer/printers-instellen" description="Network addresses and print times" />
  <Card title="Printing an invoice or receipt" href="/printer/documenten-afdrukken" description="Create jobs" />
</Cards>


# Linking actions to a product (/en-GB/producten/acties-instellen)

With actions you automate what happens after an invoice is booked or paid: topping up an NFC tag, extending an occupation, printing a receipt or creating an access method. A product can have several actions at once.

<Requires permission="Edit products" />

Before you start: the product already exists. See [Creating a product](/producten/product-aanmaken). A diagram of what Tillor does when is under [How does this fit together?](/producten#hoe-hangt-dit-samen).

<Steps>
<Step>
### Open the product [#open-het-product]

Go to <UIPath>Administration > Products</UIPath> and open the product.
</Step>
<Step>
### Tick the actions [#vink-de-acties-aan]

On the right, find the **Invoice line actions** card. Tick the actions you want. For some actions, extra fields appear afterwards. What each action does and which fields belong to it is explained in [Product actions](/producten/productacties).

Leave all boxes unticked for a plain rate without follow-up.
</Step>
<Step>
### Save [#sla-op]

Click **Save** at the bottom of the **Extra invoice lines** card. The actions are now on the product and are copied to new invoice lines.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

When you pick the product on an invoice line, Tillor copies the actions with the configured values to that line. Which action does something when depends on the type. Some actions run when the invoice is booked, most on payment.

| Moment | Actions |
|--------|--------|
| On booking | **Extend Occupation Period** (adjusts **Invoiced until**), **Request contact details** (booking is only possible once the required fields are filled in), create a reservation at **Period** with **Ask for a site** |
| On payment | **Top up NFC Tag**, **Period**, **Extend Occupation Period** (adjusts **Paid until**), **Extend access method**, **Create access method**, **Thermal print** and **A4 print** |
| No side effect | **Meter consumption** (determines the rate), **Show alert** (shows a text) |
| Blocks booking | **Prevent booking** |

In the product list you see in the **Action** column which actions a product has.

<Callout type="info">
A change to a product's actions applies to invoice lines that you add afterwards.
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the field I am looking for">
Extra fields only appear after you have ticked the matching action. You only see **Check in on booking** and **Check in on payment** if **Ask for a site** is switched on.
</Accordion>
<Accordion title="The action does not happen on payment">
Check whether the action is filled in on the invoice line itself. For **Create access method**, for example, a type must be chosen. Without a type Tillor creates nothing, and for a line that is not optional you cannot book the invoice.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Product actions" href="/producten/productacties" description="All actions and their settings" />
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" />
</Cards>


# Setting up extra invoice lines (/en-GB/producten/bundel-instellen)

Some products are more than one line on an invoice: Pitch fee with surcharges, an explanation, meter rental or NFC tags. For that you set up a bundle of extra lines on the main product. When someone picks that product as the anchor line on a draft invoice, Tillor adds the child lines under that anchor line, in the order you set.

```mermaid
flowchart TD
  hoofd[Hoofdregel: product met bundel] --> stap1[Stap 1 in bundel]
  stap1 --> kind1[Kindregel op factuur]
  hoofd --> stap2[Stap 2 in bundel]
  stap2 --> kind2[Kindregel op factuur]
```

<Requires permission="Edit products" />

## Creating or editing a bundle [#een-bundel-aanmaken-of-bewerken]

<Steps>
<Step>
### Open the main product [#open-het-hoofdproduct]

Go to <UIPath>Administration > Products</UIPath> and open the product, for example Pitch fee.
</Step>
<Step>
### Start the bundle [#start-de-bundel]

Find the **Extra invoice lines** card under **General**. If the product has no bundle yet, click **Configure bundle**.
</Step>
<Step>
### Add steps [#voeg-stappen-toe]

Click **Product step** for a line with a product and amount, or **Info step** for a line with text only. Fill in the fields per step. What each field does is explained in [Bundle steps](/producten/bundel-velden).
</Step>
<Step>
### Put the steps in the right order [#zet-de-stappen-in-de-juiste-volgorde]

With the arrows **Move step up** and **Move step down** you determine the order on the invoice. **Delete step** removes a step.
</Step>
<Step>
### Save [#sla-op]

Click **Save** at the bottom of the card.
</Step>
</Steps>

<Callout type="info">
**Save** under **Extra invoice lines** saves the whole product page, including changes in **General** and **Invoice line actions**. Every product step must have a product and every info step must have a text. Otherwise Tillor does not keep the bundle.
</Callout>

With **Remove entire bundle** you switch the bundle off. A bundle can have at most 40 steps.

## Example: a Pitch fee bundle [#voorbeeld-een-staangeld-bundel]

A typical bundle for Pitch fee consists of five steps. The steps with a formula paste the formula from [Bundle steps](/producten/bundel-velden#voorbeelden) into the **Formula** field.

<Steps>
<Step>
### Explanation [#toelichting]

An **Info step** with the text "Tourist, municipal and provincial taxes included".
</Step>
<Step>
### First NFC included [#eerste-nfc-inbegrepen]

A **Product step** with the NFC surcharge product and a formula that returns the customer's first active NFC tag with quantity 0 and price 0. Switch on **Multiply by anchor line quantity** and **Once per invoice**, choose **Line style** **INFO** and, at **Extra days after anchor end (access methods)**, enter for example `20`.
</Step>
<Step>
### Extra NFC tags [#extra-nfc-tags]

The same product step with a formula that returns the second, third and so on active NFC tag at the product rate, with the same scaling and extension options. Switch on **Once per invoice** here too.
</Step>
<Step>
### Meter rental [#meterhuur]

A **Product step** with the meter rental product and a formula that picks from `{meters}` the meters that count, for example only ICY electricity meters with supply on, and returns a line per meter with the meter name in the description.
</Step>
<Step>
### Dogs [#honden]

A **Product step** with the dog product and a formula that reads the number of dogs from a custom field of the customer and returns one line with that number, or no line when there are no dogs.
</Step>
</Steps>

## Extending NFC via the bundle [#nfc-verlengen-via-de-bundel]

For Pitch fee with NFC tags, three things belong together:

1. The main product has the action **Extend Occupation Period**, and a terrain has been chosen on the invoice line.
2. The bundle has at least one step with **Extra days after anchor end (access methods)** filled in, for example the NFC steps from the example above.
3. The main product has the action **Extend access method** with the desired types, statuses and optionally an end weekday and time.

When a line of such a step is paid, Tillor sets the validity of the customer's access methods to the end date of the Pitch fee anchor line plus the extra days. By default it runs until 23:59 in the organisation's time zone, or until the weekday and time you set at **Extend access method**. If the anchor line has no end date, Tillor extends nothing.

<Callout type="warn" title="Note">
**Extra days after anchor end (access methods)** only works if the product has **Extend Occupation Period** as an action. If the field shows a message saying this is needed, tick **Extend Occupation Period** on the right at **Invoice line actions**.
</Callout>

## What happens on a draft invoice? [#wat-gebeurt-er-op-een-conceptfactuur]

- Child lines only appear under the anchor line after you have chosen a terrain at **Extend Occupation Period**.
- Tillor rebuilds the child lines when you change the product, the quantity or the terrain on the anchor line. In other cases, child lines you edited by hand stay as they are. If you remove a meter line, for example, it does not come back by itself.
- In the invoice editor you see a preview of the child lines, including the effect of **Once per invoice**, so it matches what is there after saving.
- With the arrows you only move an anchor line as a whole block. Child lines you only move within their bundle. If you delete the anchor line, the child lines disappear with it.
- On the PDF, ordinary child lines often get a **↳** before the description. Info lines appear as grey lines without amounts.
- Tillor skips steps without a chosen product. A product that has since been deleted or is missing therefore produces no line.

## Problems? [#problemen]

<Accordions>
<Accordion title="The child lines do not appear under the anchor line">
For a main product with **Extend Occupation Period** you must first choose a terrain on the anchor line. For NFC extension on payment, the anchor line also needs an end date.
</Accordion>
<Accordion title="The same surcharge appears twice on the invoice">
If an invoice has two or more anchor lines with a bundle, each anchor line gets the bundle lines. Switch on **Once per invoice** for the steps that may only appear once. The step then only belongs to the first anchor line in invoice order.
</Accordion>
<Accordion title="The bundle is not kept">
Check whether every product step has a **Product** and every info step has an **Info line text**.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Bundle steps" href="/producten/bundel-velden" description="Fields, dynamic keys and placeholders" />
  <Card title="Bundle JSON" href="/producten/bundel-json" />
  <Card title="Product actions" href="/producten/productacties" />
</Cards>


# Bundle JSON (/en-GB/producten/bundel-json)

The **Extra invoice lines** card saves a bundle as JSON on the product, under the key `invoiceBundle`. For imports you use the same structure. For normal use you do not need this page: the fields and their explanation are on [Bundle steps](/producten/bundel-velden).

## Structure [#structuur]

| Field | Meaning |
|------|-----------|
| `invoiceBundle.version` | Always `1` |
| `invoiceBundle.steps` | List of steps, at most 40. The order is the order of the child lines on the invoice |

Every step is either a product step or an info step.

### Product step [#productstap]

| Field | Meaning |
|------|-----------|
| `productId` | An existing product in your organisation. Required |
| `quantity` | A number greater than 0, default `1`. The quantity of the line without a formula, or when the formula returns `true` |
| `quantityScale` | Optional. `"anchor_line_quantity"` multiplies every calculated quantity by the quantity of the anchor line |
| `description` | Optional. Text for the invoice line instead of the product name; a formula can give each line its own `description` |
| `style` | Optional. `DEFAULT` or `INFO` |
| `billOncePerInvoice` | Optional. `true` keeps the step with the first anchor line when an invoice has several anchor lines |
| `extendAccessMethod` | Optional. `{ "daysAfterPeriodEnd": <integer, 0 to 3660> }`, see [NFC extension](#nfc-verlenging) |
| `formula` | Optional. TypeScript that decides which lines the step produces, see [Formula](#formule) |

### Info step [#inforestap]

```json
{
  "stepKind": "info",
  "description": "Inclusief toeristen-, gemeente- en provincietaksen"
}
```

`description` is required and an info step has no `productId`. With `style` (`DEFAULT` or `INFO`) you choose the line style; the default is `INFO`. A `formula` that returns `false` leaves out the info line.

## Formula [#formule]

`formula` is TypeScript that, when an invoice is saved, returns `true` (one line with `quantity`), `false` (no line), a number (the quantity) or a list of lines `{ "quantity", "description", "unitPrice", "accessMethodValue" }`. Which fields and lists you can read and what each form does is described under [Formula per step](/producten/bundel-velden#formule-per-stap). A formula that does not compile is rejected when the product is saved. In JSON the formula is a single string with `\n` for line breaks.

```json
"formula": "return {customer.customFields.exemptFromSurcharges} !== true;"
```

## NFC extension [#nfc-verlenging]

Only useful if the main product has **Extend Occupation Period** as an action.

```json
"extendAccessMethod": { "daysAfterPeriodEnd": 20 }
```

When a line from such a step is paid, Tillor sets the validity of the customer's access methods to the end date of the anchor line plus `daysAfterPeriodEnd` calendar days. By default this runs until 23:59 in the organisation's time zone, or until the weekday and time of **Extend access method** on the main product. Which types and statuses count is also set there. Without an end date on the anchor line, nothing happens. With **Do not shorten on extend** switched on, Tillor skips methods whose validity is already on or after the new date. An `accessMethodValue` on the line names the method of that line; the extension itself follows the settings of the main product.

After a successful extension, the invoice timeline shows a line that refers to the payment.

## Example: explanation, NFC surcharge, meter rental and dogs [#voorbeeld-toelichting-nfc-toeslag-meterhuur-en-honden]

```json
{
  "invoiceBundle": {
    "version": 1,
    "steps": [
      {
        "stepKind": "info",
        "description": "Inclusief toeristen-, gemeente- en provincietaksen"
      },
      {
        "productId": "prd_nfc_toeslag",
        "quantity": 1,
        "quantityScale": "anchor_line_quantity",
        "extendAccessMethod": { "daysAfterPeriodEnd": 20 },
        "style": "INFO",
        "billOncePerInvoice": true,
        "formula": "const nfc = {accessMethods}.filter((a) => a.type === \"NFC\" && a.status === \"ACTIVE\");\nreturn nfc.slice(0, 1).map((a) => ({ quantity: 0, unitPrice: 0, accessMethodValue: a.value, description: `Toegangsmethode inclusief: ${a.label}` }));"
      },
      {
        "productId": "prd_nfc_toeslag",
        "quantity": 1,
        "quantityScale": "anchor_line_quantity",
        "extendAccessMethod": { "daysAfterPeriodEnd": 20 },
        "billOncePerInvoice": true,
        "formula": "const nfc = {accessMethods}.filter((a) => a.type === \"NFC\" && a.status === \"ACTIVE\");\nreturn nfc.slice(1).map((a) => ({ quantity: 1, accessMethodValue: a.value, description: `Toeslag extra toegangsmethode: ${a.label}` }));"
      },
      {
        "productId": "prd_meterhuur",
        "quantity": 1,
        "quantityScale": "anchor_line_quantity",
        "formula": "return {meters}.filter((m) => m.provider === \"ICY\" && m.type === \"ELECTRICITY\" && m.icyMetadata?.switchState === true).map((m) => ({ quantity: 1, description: `Huur digitale elektriciteitsmeter ${m.name}` }));"
      },
      {
        "productId": "prd_hond",
        "quantity": 1,
        "quantityScale": "anchor_line_quantity",
        "billOncePerInvoice": true,
        "formula": "const dogs = Math.max(0, Math.floor(Number({customer.customFields.animals.dogs}) || 0));\nreturn dogs === 0 ? false : [{ quantity: dogs, description: `Honden (${dogs})` }];"
      }
    ]
  }
}
```

<Callout type="warn" title="Note">
Check that all `productId` values on product steps exist in your catalogue. Tillor skips steps with an unknown product.
</Callout>

## See also [#zie-ook]

<Cards>
  <Card title="Bundle steps" href="/producten/bundel-velden" />
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" />
</Cards>


# Bundle steps (/en-GB/producten/bundel-velden)

This page describes the fields in the **Extra invoice lines** card on the product page. How to build a bundle is described in [Setting up extra invoice lines](/producten/bundel-instellen).

## Product step [#productstap]

Tillor turns a product step into zero, one or more invoice lines with that product. Without a formula that is one line with the quantity you set; with a [formula](#formule-per-stap) you decide yourself whether lines appear, how many and which.

| Field | What it does |
|------|--------------|
| **Product** | The product that goes on the child line, for example an NFC surcharge or meter rental. Required |
| **Quantity** | The quantity of the line if the step has no formula, or if the formula returns `true`. Greater than 0 |
| **Multiply by anchor line quantity** | Multiplies every calculated quantity by the quantity of the anchor line, for example 0.5 for half a year of Staangeld. The result is rounded to two decimals. Tillor leaves out lines that end up at 0 because of this; a line that the formula itself returns with quantity 0 stays |
| **Description (optional)** | Replaces the product name on the invoice line. A formula that returns lines can give each line its own description |
| **Line style** | **Default (product)**, **DEFAULT** or **INFO**. With **INFO** the child line becomes a grey explanatory note on the PDF and in the editor |
| **Once per invoice** | Only relevant if two or more anchor lines with a bundle are on the same invoice. The step then belongs only to the first anchor line in invoice order |
| **Extra days after anchor end (access methods)** | Only useful if the main product has **Extend Occupation Period** as an action. When a line from this step is paid, Tillor extends the customer's access methods to the end date of the anchor line plus this number of days; types and statuses come from **Extend access method** on the main product, see [Extending NFC via the bundle](/producten/bundel-instellen#nfc-verlengen-via-de-bundel) |
| **Formula** | Optional. TypeScript that decides whether the step appears on the invoice, with which quantity, or which lines exactly, see [Formula per step](#formule-per-stap) |

## Info step [#inforestap]

An info step is text only, without a product or amount. Tillor shows it as an explanatory line.

| Field | What it does |
|------|--------------|
| **Info line text** | The visible text, for example "Inclusief toeristen-, gemeente- en provincietaksen". Required |
| **Line style** | **INFO** by default. You can choose **DEFAULT** if you want to show the line as a normal line |
| **Formula** | Optional. If the formula returns `false`, the info line is left out |

If an info step is placed under an anchor line, the PDF automatically puts **↳** in front of the text.

## Formula per step [#formule-per-stap]

Every step can have a **Formula**: TypeScript, just like the [rate formula](/terreinen#tariefformule), which Tillor runs when an invoice with this bundle is saved. That way a step can depend on the customer, the occupation, the terrain, the meters or the access methods, for example via a [custom field](/eigen-velden) in which you record an exception.

### What the formula returns [#wat-de-formule-teruggeeft]

| Returned value | Effect |
|---------------------|--------|
| `true` | One line with the set **Quantity** |
| `false` or `null` | No line |
| A number greater than 0 | One line with that number as quantity |
| A list of lines | Exactly those lines, in that order. An empty list means no line |

A line in such a list is an object with these fields:

| Field | Meaning |
|------|-----------|
| `quantity` | Required. The quantity, 0 or more. A line with 0 stays, even with **Multiply by anchor line quantity** |
| `description` | Optional. The description of this line; otherwise the step's **Description**, otherwise the product name |
| `unitPrice` | Optional. Unit price including VAT, like the product rate; otherwise the product rate. `0` makes a free line |
| `accessMethodValue` | Optional. The value of the access method this line is about (the UID of the NFC tag), for the extension on payment |

### What the formula can read [#wat-de-formule-kan-lezen]

You read fields with curly braces, as in automations. The **Variable** menu next to the field shows everything that is available, including your own fields.

| Variable | What it is |
|-----------|------------|
| `{customer.…}` | The customer on the invoice, for example `{customer.createdAt}` or `{customer.customFields.meterhuurVrijgesteld}` |
| `{occupation.…}` | The occupation of the anchor line. If the main product is not on **Extend Occupation Period**, it is the customer's only occupation; empty (`null`) if the customer occupies several terrains |
| `{terrain.…}` | The terrain of that occupation |
| `{anchor.…}` | The anchor line: `{anchor.quantity}` (for example 0.5 for half a year), `{anchor.terrainId}`, `{anchor.occupationId}` and `{anchor.endDate}` |
| `{meters}` | The list of meters in scope: on the terrain of the anchor line with **Extend Occupation Period**, otherwise on all terrains the customer occupies. Each meter has `name`, `provider` (for example `ICY`), `type` (for example `ELECTRICITY`, `GAS`), the metadata of its provider (for example `icyMetadata.switchState` for supply on), its `terrain` and `customFields` |
| `{accessMethods}` | The list of the customer's access methods, oldest first, of every type and status. Each method has `type` (for example `NFC`), `status` (for example `ACTIVE`), `value`, a readable `label` (the known name of the NFC tag, otherwise the value) and `customFields` |

Tillor only loads the lists `{meters}` and `{accessMethods}` if the formula uses them.

### Examples [#voorbeelden]

Skipping a step for exempt customers:

```ts
if ({customer.customFields.exemptFromSurcharges} === true) return false;
return true;
```

One line per ICY electricity meter with supply on, and for customers since 2026 also with supply off:

```ts
const newCustomer = new Date({customer.createdAt} ?? 0) >= new Date("2026-01-01T00:00:00+01:00");
return {meters}
  .filter((m) => m.provider === "ICY" && m.type === "ELECTRICITY")
  .filter((m) => m.icyMetadata?.switchState === true || newCustomer)
  .map((m) => ({ quantity: 1, description: `Huur digitale elektriciteitsmeter ${m.name}` }));
```

The first NFC tag free as an explanation, every following one at the product rate (two steps with the same product, or one step that returns both kinds of lines):

```ts
const nfc = {accessMethods}.filter((a) => a.type === "NFC" && a.status === "ACTIVE");
return nfc.map((a, i) => ({
  quantity: i === 0 ? 0 : 1,
  unitPrice: i === 0 ? 0 : undefined,
  accessMethodValue: a.value,
  description: i === 0 ? `Toegangsmethode inclusief: ${a.label}` : `Toeslag extra toegangsmethode: ${a.label}`,
}));
```

One line with the number of dogs from a custom field of the customer, no line when there are no dogs:

```ts
const dogs = Math.max(0, Math.floor(Number({customer.customFields.animals.dogs}) || 0));
return dogs === 0 ? false : [{ quantity: dogs, description: `Honden (${dogs})` }];
```

With **Insert example** below the field you get a starting point with these forms in comments.

### Errors [#fouten]

You cannot save a formula that does not compile; the message below the field says what is wrong. If a formula gets stuck when an invoice is saved, or returns anything other than `true`, `false`, a number or valid lines, saving fails with the name of the step in the error message, so that a broken formula never silently adds or leaves out a line.

## See also [#zie-ook]

<Cards>
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" />
  <Card title="Bundle JSON" href="/producten/bundel-json" />
  <Card title="Meter management" href="/meterbeheer" />
</Cards>


# Overview (/en-GB/producten)

A product is a rate or service that you put on an invoice line: a night on a terrain, a monthly subscription, an NFC tag or a kWh of electricity. Every product has a price including VAT. You can also attach actions to it that Tillor carries out automatically, such as extending an occupation or printing a receipt. Users with the **Edit products** permission can create and change products.

You find all products under <UIPath>Administration > Products</UIPath>.

<DocScreenshot src="/screenshots/producten/products-list.png" alt="Product overview with a demo product for one night" />

<Callout type="info" title="Good to know">
- The price always includes VAT. You choose 0%, 6%, 9%, 12% or 21%.
- A change to price, ledger or actions applies to lines you add afterwards. Existing invoices do not change.
- You can schedule a new price from today or a later day, not for the past.
- A disabled product can no longer be chosen on invoices, but stays on existing invoices.
- A deleted product cannot be recovered. Disable it instead.
- For each combination of customer type and meter type there is only one product with the **Meter consumption** action.
- A **Show alert** may contain at most 4000 characters.
- For each printer you set at most 10 copies for automatic printing.
- With **Extend access method** you add at most 3660 days after the end date.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

A product does nothing as long as it is not on an invoice. If a product has actions, Tillor copies them to the invoice line. Booking and paying start those actions, and that is how the result ends up with the occupation, the tag or the printer.

```mermaid
flowchart TD
  P[Product with actions] --> R[Invoice line on a draft invoice]
  R -- Book --> G[Booked invoice]
  G --> G1[Occupation: Invoiced until moves on]
  G --> G2[Reservation created with Ask for a site]
  G --> G3[Booking blocked or contact details requested]
  G -- Pay --> B[Paid invoice]
  B --> B1[Occupation: Paid until moves on]
  B --> B2[NFC tag topped up]
  B --> B3[Access method created or extended]
  B --> B4[Receipt or A4 printed]
```

An example with **Extend Occupation Period**: you invoice monthly rent for a customer. When you book, the occupation is shown as invoiced until the end of the month. As soon as the customer pays, **Paid until** moves along. That way you can see on the occupation what has been invoiced and what has been paid. More about this is in [Occupations](/bezettingen#betaald-tot-type-huurfrequentie-en-prijs).

A credit invoice reverses this: booking sets **Invoiced until** back to the start of the line, paying sets **Paid until** back. See [Internal transfer](/betalingsverwerking/interne-overboeking) for the case where a credit invoice is only settled against the original invoice.

## What you see in the list [#wat-je-in-de-lijst-ziet]

| Column | Content |
|-------|--------|
| **Name** and **Description** | Name and explanation as you entered them on the product |
| **Info** | Customer type and meter type, only for products with the **Meter consumption** action |
| **Action** | The actions on the product. With several actions the column shows a summary |
| **Price (incl. VAT)** | Price per unit |
| **VAT %** | The VAT rate |
| **Ledger** | The ledger number, if you have entered one |

In the row you find a pencil icon to open the product and a bin icon to delete it. Both are disabled if you do not have the **Edit products** permission.

### Searching and filtering [#zoeken-en-filteren]

Type in the search bar to filter the list instantly. You can also filter on **VAT**, **Customer type**, **Meter type**, **Action type**, **Status** (<Status tone="success">Active</Status> or <Status>Disabled</Status>) and **Accounts**. With **Reset** you clear the filters in one go.

## See also [#zie-ook]

<Cards>
  <Card title="Creating a product" href="/producten/product-aanmaken" description="Set name, price, VAT and ledger" />
  <Card title="Editing or deleting a product" href="/producten/product-bewerken" description="Change details, disable or delete" />
  <Card title="Scheduling a price change" href="/producten/prijzen-plannen" description="A new price from a date and the VAT calculator" />
  <Card title="Linking actions to a product" href="/producten/acties-instellen" description="Have Tillor do something on booking or payment" />
  <Card title="Product actions" href="/producten/productacties" description="All actions and their settings" />
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" description="Automatically put surcharges and explanations under a main line" />
  <Card title="Bundle steps" href="/producten/bundel-velden" description="Fields, dynamic keys and placeholders" />
  <Card title="Bundle JSON" href="/producten/bundel-json" description="The bundle structure for imports" />
  <Card title="Practical examples" href="/praktijk" description="Worked examples from practice" />
</Cards>

## Concepts [#begrippen]

- **Product**: a price and description that can go on an invoice line.
- **Action**: something Tillor does automatically when an invoice line with this product is booked or paid.
- **Bundle**: a series of extra invoice lines that Tillor puts under a main line, for example surcharges with Staangeld.
- **Anchor line and child line**: the anchor line is the line with the bundle product, the child lines are the lines Tillor adds below it.
- **Invoiced until** and **Paid until**: until when an occupation is invoiced and paid respectively. See [Occupation](/begrippen#bezetting).
- **Ledger**: the account number in your bookkeeping that a product books to.


# Scheduling a price change (/en-GB/producten/prijzen-plannen)

If the price of a product changes from a certain day, you schedule it in advance. On that day Tillor changes the product's price by itself. Existing invoices keep their prices.

<Requires permission="Edit products" />

## Scheduling a price [#een-prijs-plannen]

<Steps>
<Step>
### Open the product [#open-het-product]
Go to <UIPath>Administration > Products</UIPath> and open the product. At the bottom of the page is the **Scheduled prices** card.

<DocScreenshot src="/screenshots/producten/product-price-changes.png" alt="Scheduled prices card with a scheduled and an applied price" />
</Step>
<Step>
### Choose the date [#kies-de-datum]
Under **Starting from**, choose the day on which the new price takes effect. Today is fine, a day in the past is not.
</Step>
<Step>
### Enter the price [#vul-de-prijs-in]
Type the **New price (incl. VAT)**. Under **VAT rate** leave **Current VAT rate** selected or choose a different rate that applies from that day. You can also choose a [regime without VAT](/boekhouden/belasting#btw-verlegd-en-andere-regimes-zonder-btw), such as **Reverse charge (EU services)**; the product is then at 0% under that regime from that day.
</Step>
<Step>
### Schedule the price [#plan-de-prijs]
Click **Schedule price**. The price appears in the list with the status <Status tone="info">Scheduled</Status>.
</Step>
</Steps>

If you choose today as the date, the new price applies immediately. For a later date, the price applies from the start of that day. Tillor uses your organisation's time zone for this.

## What happens next? [#wat-gebeurt-er-daarna]

The product gets the new price, and possibly the new VAT rate. The line in the list gets the status <Status tone="success">Applied</Status>. Tillor sends an email to your organisation's support address, or to the general email address if that is missing. The notification is called **Scheduled product price applied** and shows the old and the new price. See also [Notifications](/notificaties).

Invoices that already exist do not change. Only lines you add afterwards get the new price.

## Changing or removing a scheduled price [#een-geplande-prijs-wijzigen-of-verwijderen]

- If you schedule a price again for the same day while a scheduled price still exists, the new one replaces the old one.
- Click the bin icon next to a scheduled price and confirm with **Remove scheduled price**. The product keeps its current price on that date.
- A price with the status <Status tone="success">Applied</Status> stays as history and you cannot remove it.

## The VAT calculator [#de-btw-calculator]

Next to the price field, both at **New price (incl. VAT)** and at **Price (incl. VAT)** in **General**, there is a small calculator icon. It opens the **VAT calculator**.

<DocScreenshot src="/screenshots/producten/product-vat-calculator.png" alt="VAT calculator with VAT rate, amount excl. and incl. VAT and change price by percentage" />

In the calculator you can:

- enter the amount **Excl. VAT** or **Incl. VAT**. The other amount and the VAT are calculated immediately.
- choose a different **VAT rate**. The price incl. VAT is then recalculated from the amount excl. VAT.
- enter a percentage under **Change price by %**, for example 5 for five percent extra or -5 for five percent off, and click **Apply**.

Click **Use this price** to put the price and the VAT rate in the form. After that you still have to save or schedule the price.

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot choose a date in the past">
A price can only apply from today or later. If you want to change a price retroactively, you change the invoices themselves.
</Accordion>
<Accordion title="Schedule price is greyed out">
For that you need the **Edit products** permission.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Editing or deleting a product" href="/producten/product-bewerken" />
  <Card title="Notifications" href="/notificaties" />
</Cards>


# Creating a product (/en-GB/producten/product-aanmaken)

A new product is available on invoices straight away. You set up actions and extra invoice lines afterwards on the product page.

<Requires permission="Edit products" />

<Steps>
<Step>
### Open the dialog [#open-het-dialoogvenster]

Go to <UIPath>Administration > Products</UIPath> and click **New Product** at the top right.
</Step>
<Step>
### Fill in the basic details [#vul-de-basisgegevens-in]

<DocScreenshot src="/screenshots/producten/product-create-dialog.png" alt="Create product dialog with basic fields" />

| Field | What you enter |
|------|---------------|
| **Name** (required) | The name as it appears on invoices |
| **Description** | A short explanation (optional) |
| **Price (incl. VAT)** | The amount per unit, including VAT |
| **VAT %** | Choose from 0%, 6%, 9%, 12% or 21%, or a regime without VAT such as **Reverse charge (EU services)**. See [Reverse charge and other regimes](/boekhouden/belasting#btw-verlegd-en-andere-regimes-zonder-btw) |
| **Ledger** | The ledger number for your bookkeeping (optional) |
| **Guard the customer's balance on this ledger** | For deposits: refuses invoices that would bring the customer's balance below zero. See [Guarding the customer's balance](#het-saldo-van-de-klant-bewaken) |
</Step>
<Step>
### Create the product [#maak-het-product-aan]

Click **Create**. Tillor opens the product page, where you can add actions and extra invoice lines.
</Step>
</Steps>

<Callout type="info">
The price always includes VAT. Tillor calculates the VAT amount with the chosen percentage and shows it separately on the invoice.
</Callout>

## Ledger number [#grootboeknummer]

With the ledger number you link a product to an account in your bookkeeping. The number is used when exporting to accounting software. Leave the field empty if you do not want to link the product to an account of its own.

A change to the ledger number applies to new invoice lines. Booked invoices do not change.

## Guarding the customer's balance [#het-saldo-van-de-klant-bewaken]

For deposits, tick **Guard the customer's balance on this ledger**. Tillor then adds up, per customer, all booked invoice lines on that ledger, and refuses every invoice that would bring that balance below zero. That way you cannot accidentally refund a deposit twice. This option requires a ledger number.

On the invoice you see, below the line, the customer's balance on that ledger and what it becomes after this invoice. Drafts do not count. A booked deposit invoice also cannot be set back to draft or moved to another customer if the balance would go below zero as a result.

On the **Invoicing** tab of a customer, under **Invoices**, is the **Accounts** table: every ledger on which something has been booked for that customer or on which an [opening balance](#beginsaldi-van-voor-tillor) exists, with the balance. An account that nets to zero also stays visible. A guarded ledger on which the customer has not yet booked anything is not listed.

If at least one product guards a ledger, the **Protection** filter is set to **On** by default and you only see the guarded ledgers. Clear the filter to also see the other accounts, such as your revenue accounts. Without guarded products the filter is off and you immediately see all accounts. With the **Balance** filter you keep only the accounts that are not at zero. A small shield next to the number shows which accounts are guarded.

Expand an account and you see the booked invoices with a line on that ledger, from old to new, with the amount and the **Running balance**: the balance after that invoice. If there are more than 100 invoices on the account, you see the last 100. The running balance does include the older invoices.

With the **Override ledger balance** permission you can book anyway. You then give a reason, which appears in the invoice timeline. Without that permission **Book** stays greyed out as long as the balance would go below zero.

<Requires permission="Override ledger balance" />

## Opening balances from before Tillor [#beginsaldi-van-voor-tillor]

A deposit that the customer paid before you started with Tillor is not on an invoice in Tillor. Put such an amount as an **opening balance** on the customer's account. It counts towards the balance and the guarding, so you simply refund that deposit later, without a reason. An opening balance is not an invoice: it gets no number and no VAT, and it does not go to your bookkeeping, because your old bookkeeping already has it.

**One customer:** open the customer, **Invoicing** tab, **Accounts** card, and click **Opening balance**. Enter the account (e.g. 428002), the amount, the date of the old balance and a reference, for example the document from your old system. A negative amount is an amount the customer still owes. Expand the account and you see the opening balance at the top of the running balance, with buttons to change or delete it. Below the balance it says how much of it is opening balance.

**All customers at once:** go to <UIPath>Administration > Invoices</UIPath> and click **Import opening balances**. Paste the rows from a spreadsheet or choose a CSV file, with a header row and the columns customer (the Tillor customer number), account, amount, date, reference and optionally note. Click **Check**: you see which rows are new, which ones Tillor updates and which customers were not found, plus the total per account. Compare that total with the balance of your old bookkeeping and then click **Import**. A row with a reference that the customer already has on that account updates that opening balance instead of adding it twice, so you can safely repeat an import.

An opening balance that has already been refunded can normally no longer be deleted or reduced: the balance would then go below zero. If you have the **Override ledger balance** permission, Tillor asks for a reason in that case and carries out the change anyway, for example to remove an old, merged opening balance from a customer who already got their deposit back in Tillor. This also applies to an import that brings a balance below zero. Every change goes on the customer's timeline, with your reason added if you overrode the guarding.

<Requires permission="Manage opening balances" />

## What happens next? [#wat-gebeurt-er-daarna]

- The product is in the list straight away and you can choose it on draft invoices.
- On the product page you then set up [actions](/producten/acties-instellen), [extra invoice lines](/producten/bundel-instellen) and [scheduled prices](/producten/prijzen-plannen).

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot create or change a product">
Creating and changing requires the **Edit products** permission. Ask an administrator of your organisation to add that permission to your role.
</Accordion>
<Accordion title="I am missing a VAT rate">
You can only choose from 0%, 6%, 9%, 12% and 21%. You cannot set other rates.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Editing or deleting a product" href="/producten/product-bewerken" />
  <Card title="Linking actions to a product" href="/producten/acties-instellen" />
  <Card title="VAT and tax" href="/boekhouden/belasting" />
</Cards>


# Editing or deleting a product (/en-GB/producten/product-bewerken)

On the product page you change everything about a product. Changes take effect on new invoice lines.

<Requires permission="Edit products" />

## Editing a product [#een-product-bewerken]

<Steps>
<Step>
### Open the product [#open-het-product]

Go to <UIPath>Administration > Products</UIPath> and click the product name or the pencil icon in the row.
</Step>
<Step>
### Change the details [#pas-de-gegevens-aan]

<DocScreenshot src="/screenshots/producten/product-detail.png" alt="Product detail page with General, Extra invoice lines, Invoice line actions and Events" />

On the left you find the **General** and **Extra invoice lines** cards. On the right are **Invoice line actions** and **Events**. **General** contains the same fields as when creating, plus the **Disable product** option.
</Step>
<Step>
### Save [#sla-op]

At the bottom of the **Extra invoice lines** card, click **Save**. That button saves all changes on the page, including those in **General** and **Invoice line actions**. The button is only active once you have changed something.
</Step>
</Steps>

If you want a new price to apply only from a later date, use the **Scheduled prices** card. See [Scheduling a price change](/producten/prijzen-plannen).

Under **Events** you see a timeline of changes to the product, such as price, ledger and actions. Each change shows the time, the user and, where possible, the difference between before and after.

## Disabling a product [#een-product-uitschakelen]

Tick **Disable product** and save. A disabled product can no longer be chosen on invoices, but it stays in the list and on existing invoices. In the list and on the product page you see it as <Status>Disabled</Status>. That way you keep the history without using the product any more.

## Deleting a product [#een-product-verwijderen]

<Steps>
<Step>
### Choose delete [#kies-verwijderen]

In the list, click the bin icon next to the product. On the product page, open the menu with the three dots in the header and choose **Delete product**.
</Step>
<Step>
### Confirm [#bevestig]

<DocScreenshot src="/screenshots/producten/product-delete-dialog.png" alt="Confirmation dialog for deleting a product" />

In the dialog, click **Delete**.
</Step>
</Steps>

<Callout type="warn" title="Note">
Deleting cannot be undone. Invoices that already contain the product stay unchanged. If the product is a step in the bundle of another product, Tillor skips that step from then on. If you just want to stop using the product, disable it instead.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- A new price, different ledger or different action applies to lines you add afterwards. Existing invoices stay as they were.
- A disabled product disappears from the selection list on invoices, but stays visible in the product list.
- Every change goes on the product's **Events** timeline, with user and time.

## Problems? [#problemen]

<Accordions>
<Accordion title="Save is greyed out">
The button only works after you have changed something, and only with the **Edit products** permission.
</Accordion>
<Accordion title="The bundle is not saved">
Every product step in the bundle must have a product and every info step must have a text. Complete that and save again. See [Setting up extra invoice lines](/producten/bundel-instellen).
</Accordion>
<Accordion title="Saving fails for a product with Meter consumption">
For each combination of customer type and meter type there can be only one product with the **Meter consumption** action. If that combination is already on another product, saving is refused. Change that other product or choose a different combination.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Linking actions to a product" href="/producten/acties-instellen" />
  <Card title="Scheduling a price change" href="/producten/prijzen-plannen" />
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" />
</Cards>


# Product actions (/en-GB/producten/productacties)

You switch actions on on the product page, in the **Invoice line actions** card. How to do that is described in [Linking actions to a product](/producten/acties-instellen). This page describes every action. How the actions on booking and payment fit together with occupations, tags and printers is explained under [How does this fit together?](/producten#hoe-hangt-dit-samen).

## Top up NFC Tag [#nfc-tag-opladen]

When an invoice with this product is paid, Tillor automatically tops up an NFC tag. Use this for products with which customers get balance or access on a tag. There are no extra fields on the product.

## Period [#periode]

The product stands for a service over a period of time, such as a day rate, weekly subscription or monthly rate.

| Field | Meaning |
|------|-----------|
| **Per unit** | Number of units per period, at least 1 |
| **Period unit** | **Day**, **Week** or **Month** |
| **Auto-extend access methods** | On payment Tillor extends all of the customer's access methods to the end date of the period |
| **Ask for a site** | On the invoice line you choose a terrain. When booking, Tillor creates a reservation for that stay |
| **Check in on booking** | Only with **Ask for a site**. As soon as the invoice is booked, Tillor sets the reservation to <Status tone="success">Checked in</Status> |
| **Check in on payment** | Only with **Ask for a site**. As soon as the invoice is paid, Tillor sets the reservation to <Status tone="success">Checked in</Status> |
| **Included adults** | Only with **Ask for a site**. Number of adults on the reservation, default 2. You can enter 0 to 99 |

### Reservations with Ask for a site [#reserveringen-bij-terrein-vragen]

- The reservation gets the same arrival and departure as the invoice line and the chosen terrain as a preference. You adjust the party afterwards on the reservation itself.
- If you set the invoice back to draft and change the dates or the terrain, Tillor updates the same reservation when booking again.
- If you remove the terrain or switch **Ask for a site** off, the reservation is cancelled. A reservation that has already been checked out stays.
- A credit note cancels the reservation of the original invoice.
- Without check-in the reservation stays on <Status tone="info">Booked</Status>. That is how a reservation deposit works: a terrain and dates in the future, without arrival.
- If both check-in options are on, booking counts.
- If the invoice has already been paid at the moment you book again, Tillor checks in again.

On the timeline of the invoice and of the reservation you see the creating, changing, cancelling and checking in, with a reference to the other.

## Extend Occupation Period [#bezetting-verlengen]

With this action an invoice extends a customer's occupation on a terrain, for example for Staangeld.

- When **booking**, Tillor changes **Invoiced until** of the occupation.
- On **payment**, Tillor changes **Paid until**.

On the invoice line you choose a terrain. When booking and paying, Tillor links the customer's active occupation on that terrain. Tillor also keeps a copy of that occupation on the line, so that afterwards you can see which occupation was meant, even if it was deleted later. With **Round to next period boundary** on the invoice line you align customers on instalments to the same cycle, according to the **Rent frequency** of the occupation.

If you choose a terrain on which the customer does not have an occupation yet, you are making a quote. You can only book such a line once the customer has the terrain in occupation.

| Field | Meaning |
|------|-----------|
| **Due date from occupation start** | When booking, Tillor sets the due date to the start date of the occupation period on the Staangeld line, instead of the standard payment term or the term in the booking dialog. When booking again, the original due date stays |

If the product has extra invoice lines, Tillor adds child lines under the anchor line. See [Setting up extra invoice lines](/producten/bundel-instellen).

## Extend access method [#toegangsmethode-verlengen]

With this action the payment of an invoice extends the validity of the customer's access methods. It works in two ways:

- **Together with Period** on the same line, for example monthly rent. Tillor extends the chosen methods to the end date of the period.
- **Via a bundle** with a Staangeld anchor line and NFC steps. The end date of the Staangeld anchor line is then the basis. The settings below come from the main product, not from the surcharge product of the NFC step. See [Extending NFC via the bundle](/producten/bundel-instellen#nfc-verlengen-via-de-bundel).

| Field | Meaning |
|------|-----------|
| **Days after end date** | Calendar days on top of the end date. 0 means the end date itself, at most 3660. With bundles you set this per NFC step |
| **Weekday** | Optional. The validity ends on the nearest occurrence of that weekday around the target date. Default **Any day** |
| **Time** | Optional. Clock time in the organisation's time zone. Empty means 23:59 |
| **Access method types** | Choose at least one type from NFC, QR code, License Plate Recognition and PIN code. You only see the types that are enabled for your organisation |
| **Statuses** | Only methods with one of these statuses are extended: <Status tone="success">Active</Status> or <Status tone="warning">Soft blocked</Status>. By default only **Active** |
| **Do not shorten on extend** | Methods whose **Valid until** is already on or after the new date are skipped. When reversing via a credit note, Tillor always sets the calculated date |

Below the field is a **Result** line that explains at what moment the validity ends up, for example "nearest Tuesday around end date + 10 days, at 13:00".

This is not the same as **Auto-extend access methods** under **Period**. That switch extends on payment of a product with only **Period**, without the separate **Extend access method** action.

## Create access method [#toegangsmethode-aanmaken]

When the invoice is paid, Tillor creates a new access method for the customer. The cashier chooses the type on the invoice line. If the line also has the **Period** action, the period becomes the validity of the access method.

| Field | Meaning |
|------|-----------|
| **Access method types** | Types from which the cashier chooses: QR code, License Plate Recognition or PIN code. With a single type, Tillor chooses it automatically |
| **Access method is optional** | Booking is never blocked by this line. Without a chosen type, Tillor creates nothing |
| **Default access method** | Only with several types. This type is selected by default on new invoice lines, adjustable per line. **No default (choose per line)** leaves the choice open |
| **Print QR code automatically** | Only with QR code. Tillor prints the QR access ticket on the receipt printer as soon as it is created |
| **Auto-convert codes to license plate** | New QR and PIN codes are replaced by the detected licence plate when they are used at a gate with a camera. Adjustable per line |

A line can only be booked once a type has been chosen, unless the action is optional. With License Plate Recognition the licence plate must also be filled in.

## Request contact details [#contactgegevens-vragen]

Fields for email address and phone number appear on the invoice line. Tillor asks for them when booking.

| Field | Meaning |
|------|-----------|
| **Ask for email address** | Shows an email field on the invoice line |
| **Email address required** | Only if you ask for an email address. Booking is blocked until the field is filled in |
| **Ask for phone number** | Shows a phone field on the invoice line |
| **Phone number required** | Only if you ask for a phone number. Booking is blocked until the field is filled in |

## Prevent booking [#boeken-blokkeren]

Use this for products that only belong on draft invoices. If such a line is on a draft invoice, you cannot finalise the invoice. There is no extra field. Tillor blocks booking as long as the line is there.

## Show alert [#melding-tonen]

Shows an alert below the invoice line, for example "Note: only use for day visitors". Nothing happens on booking or payment.

| Field | Meaning |
|------|-----------|
| **Alert style** | **Info**, **Warning**, **Error**, **Success** or **Neutral** |
| **Alert text** | The text, at most 4000 characters. Markdown is supported (bold, lists, links) |

Below the text you immediately see a preview of the alert. The text is copied to the invoice line. Later changes to the product do not change existing invoices.

## Meter consumption [#meterverbruik]

With this action the product becomes the rate for meter consumption. Tillor uses it for outstanding consumption and for automatic invoicing of meter readings. You choose two fields.

| Field | Options |
|------|-------|
| **Customer type** | **Standard**, **Worker Rental Caravan**, **Worker Towing Caravan** |
| **Meter Type** | **Electricity**, **Water**, **Gas** |

For each combination of customer type and meter type there can be only one product. In the list both values are in the **Info** column. If a customer has no product of their own for their customer type, Tillor uses the product for **Standard** with the same meter type.

## Thermal print and A4 print [#thermisch-printen-en-a4-printen]

Tick **Thermal print** and **A4 print** separately. As soon as at least one of the two is on, the **Automatic printing** block appears. There you set per printer what is printed when the invoice is paid.

| Field | Meaning |
|------|-----------|
| **Thermal print copies** | Number of copies on the thermal printer (receipt printer). 0 switches that printer off |
| **A4 print copies** | Number of copies on the A4 printer. 0 switches A4 off |
| **Print timing** | **Use settings (per payment type)** (default), **Print immediately** or **Next cutoff time** |

You can set at most 10 copies per printer. With **Use settings (per payment type)** your organisation's setting per payment type applies.

## See also [#zie-ook]

<Cards>
  <Card title="Linking actions to a product" href="/producten/acties-instellen" />
  <Card title="Setting up extra invoice lines" href="/producten/bundel-instellen" />
  <Card title="Meter management" href="/meterbeheer" />
  <Card title="NFC" href="/nfc" />
</Cards>


# Reservations (/en-GB/reserveringen)

With reservations you keep track of the stays at your park: who is coming when, on which terrain and with how many guests. From a reservation you also handle check-in and check-out. You see all reservations on a timeline under **Reservations** and per customer on the **Reservations** tab. Start with [Creating a reservation](#een-reservering-aanmaken).

<Callout type="info" title="Good to know">
- Every reservation belongs to a customer and automatically gets a unique **Reservation number**. You cannot change that number.
- The check-out date must be after the check-in date. Tillor refuses the same day or earlier.
- A licence plate consists of letters and digits, at most 10 characters, without spaces or hyphens.
- Check-in and cancellation are only possible from the **Booked** status. Cancelling is no longer possible after check-in.
- A reservation is not the same as an occupation: a reservation is a booking for a stay, an occupation links a customer to a terrain for a period, see [Occupations](/bezettingen).
- Notes on a reservation are internal and are never shared with the customer.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  K[Customer] --> R[Reservation]
  R -->|Check in| I[Guest on the terrain]
  I -->|Check out| U[Stay completed]
  R -->|Cancel reservation| A[Cancelled]
  R --> F[Customer's invoices]
```

You find the customer's invoices on the customer profile under **Invoicing**.

## The timeline [#de-tijdlijn]

Go to **Reservations** in the main menu. The timeline shows the reservations per terrain across a calendar. With the view you choose day, week, month, quarter or year, and you jump to a date with **Go to date**.

<DocScreenshot src="/screenshots/reserveringen/reservations-list.png" alt="Timeline of reservations" />

- Click or drag on a free stretch to add a reservation. At the top right there is also **New reservation**.
- If you drag a reservation to other dates, Tillor asks **Update reservation dates?** The reservation only changes after you confirm.
- The context menu of a reservation has **View reservation**, **Copy link** and **Cancel reservation**.

## Creating a reservation [#een-reservering-aanmaken]

Before you begin:

- You need a customer. If they do not exist yet, you create them while starting, see [Customer management](/klantenbeheer).
- Do you know which terrain the guest wants? Then choose it. Otherwise leave the field empty.

<Steps>
<Step>
### Start the reservation [#start-de-reservering]
<Tabs items={["Via Reservations", "Via the customer profile"]}>
<Tab value="Via Reservations">
Click **New reservation** at the top right. Choose an existing customer or create a new customer.
</Tab>
<Tab value="Via the customer profile">
Open the customer via **Customers**, go to the **Reservations** tab and click **New reservation**.
</Tab>
</Tabs>
</Step>
<Step>
### Fill in the form [#vul-het-formulier-in]
See [The reservation form](#het-reserveringsformulier) below for all fields.
</Step>
<Step>
### Create the reservation [#maak-de-reservering-aan]
Click **Create reservation**.
</Step>
</Steps>

### What happens next? [#wat-gebeurt-er-daarna]

- The reservation gets the status <Status tone="info">Booked</Status> and a reservation number.
- If **Automatic confirmation email** is on, the customer receives a confirmation.
- You find the reservation on the timeline and on the customer's **Reservations** tab.
- If you want an automation to react to a new or changed reservation, use a trigger, see [Triggers](/automatiseringen/triggers).

## The reservation form [#het-reserveringsformulier]

### Dates and length of stay [#datums-en-verblijfsduur]

- **Check-in**: choose the arrival date.
- **Check-out**: choose the departure date. After the check-in date the check-out picker opens by itself. The departure date must be after the arrival date.
- **Number of nights**: Tillor calculates this itself.

### Numbers and animals [#aantallen-en-dieren]

Enter the number of **Adults** (at least 1), **Children**, **Toddlers** and **Animals** with the plus and minus buttons.

### Terrain [#terrein]

- **Terrain**: choose a terrain if the guest has a preference. The list only shows bookable terrains without an active occupation that are free in the chosen period. Tillor excludes overlapping active reservations on the same terrain. If you change the dates, the list refreshes. No preference? Leave the field empty.
- **Include non-bookable sites**: also shows terrains that cannot be reserved online, for example permanent annual pitches. If the reservation is already on such a terrain, this box is ticked automatically.
- **Include occupied sites**: also shows terrains that already have an occupation.

### Licence plates [#nummerplaten]

Type a licence plate, press **Enter** and repeat this for every plate. A cross on a plate removes it. Licence plates may only contain letters and digits, at most 10 characters.

The licence plates on a reservation can be found via search. You arrange access at the barrier separately, on the customer's **Access Control** tab, see [Access control](/toegangscontrole).

### Notes [#notities]

Use the notes field for internal remarks, such as special requests or agreements.

### Communication preferences [#communicatievoorkeuren]

- **Automatic confirmation email**: sends a confirmation after creating.
- **Online payment**: allows the customer to pay the reservation online.

## Viewing and editing a reservation [#een-reservering-bekijken-en-bewerken]

Click a reservation on the timeline or in the customer profile to open the detail page.

<DocScreenshot src="/screenshots/reserveringen/reservation-detail.png" alt="Detail page of a reservation" />

- **Reservation details** (left): the complete form. Change what you want and click **Save**. With **Cancel** you restore the original values. Next to the title is **Copy reservation link**, handy for pasting a clickable link into a document.
- **Reservation actions** (right): the buttons below.
- **Comments** (right): internal discussion about this reservation.
- **Activity** (right): a timeline with creating, check-in, check-out, cancelling, reversing and changed details, with time and user. For a change you see which fields were changed (before / after).

## Checking in, checking out and cancelling [#inchecken-uitchecken-en-annuleren]

On the detail page the actions are under **Reservation actions**. Every action asks for confirmation.

| Action | Possible when | Result |
|---|---|---|
| **Check in** | Status <Status tone="info">Booked</Status> | Status <Status tone="success">Checked in</Status> |
| **Check out** | Status <Status tone="success">Checked in</Status> | Status <Status>Checked out</Status> |
| **Cancel reservation** | Only before check-in | Status <Status>Cancelled</Status> |
| **Undo cancellation** | Only before check-in | Back to <Status tone="info">Booked</Status> |
| **Undo check-in** | For a wrong check-in. If the guest was already checked out, first reverse the check-out | Back to <Status tone="info">Booked</Status> |
| **Undo check-out** | For a wrong check-out | Back to <Status tone="success">Checked in</Status> |

In addition there are **Send confirmation form to customer (SMS)** and **Create task**. With the latter you make a task from this reservation.

A cancelled reservation cannot be checked in or checked out. First undo the cancellation.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says: Reservation not created">
The message is **The reservation could not be created.** Check whether a customer has been chosen and whether the check-out date is after the check-in date. The same day or earlier is refused.
</Accordion>
<Accordion title="Tillor says: Reservation not updated">
Your changes have not been saved. Check the dates (check-out must be after check-in), the licence plates and the number of adults, and click **Save** again.
</Accordion>
<Accordion title="Tillor says: Check-in failed">
The reservation must have the Booked status. If it has already been checked in, checked out or cancelled, check-in is not possible. Reload the page and see what the status is now. If it has been cancelled, first use **Undo cancellation**.
</Accordion>
<Accordion title="Tillor says: Check-out failed">
Check-out is only possible for a reservation that has been checked in. If the guest has not yet been checked in or has already been checked out, it does not work.
</Accordion>
<Accordion title="Tillor says: Cancelling failed">
Cancelling is only possible before check-in. If the guest has already been checked in, first use **Undo check-in** and then cancel.
</Accordion>
<Accordion title="The terrain is not in the list">
The list only shows bookable terrains without an occupation that are free in the chosen period. Check the dates. Tick **Include non-bookable sites** or **Include occupied sites** if you mean such a terrain.
</Accordion>
<Accordion title="A licence plate is not added">
A licence plate may only contain letters and digits and be at most 10 characters long. Remove spaces and hyphens.
</Accordion>
</Accordions>

## Concepts [#begrippen]

- **Reservation**: a booking for a stay. See [reservation](/begrippen#reservering).
- **Booked, Checked in, Checked out, Cancelled**: the four statuses of a reservation.
- **Reservation number**: the automatic number with which you find a reservation again.
- **Occupation**: a customer on a terrain for a period, separate from a reservation. See [occupation](/begrippen#bezetting).
- **Timeline**: the overview of reservations per terrain across a calendar.

## See also [#zie-ook]

<Cards>
  <Card title="Customer management" href="/klantenbeheer" />
  <Card title="Occupations" href="/bezettingen" />
  <Card title="Access control" href="/toegangscontrole" />
  <Card title="Payment processing" href="/betalingsverwerking" />
  <Card title="Practical examples" href="/praktijk" />
</Cards>


# Share tasks (/en-GB/taken/delen)

Do you want to show tasks to someone who does not work in Tillor, or see them in your own calendar? Then you create a share link. There are two kinds.

| Type | What it is |
|---|---|
| **Shareable page** | A read-only board showing what needs to be done. It follows the tasks, so changes in Tillor show up there |
| **Calendar (ICS)** | A calendar subscription for Google Calendar, Outlook or Apple Calendar, for example |

## Create a link [#een-link-maken]

1. Click the share icon at the top right of the tasks page (tooltip **Share this view**). You will find the same icon on the dashboard card **Tasks for you**
2. Under **Link type**, choose a **Shareable page** or **Calendar (ICS)**
3. Under **Contents**, choose what you share: **My assigned tasks** or one of your views. If you open the window from a view, it is already selected
4. If you like, narrow the contents with **Filters**: **Status**, **Priority**, **Assigned to**, **Label**, **View**, **Linked to** and **Blocked**. The filters are saved on the link and only narrow down what the source already shows
5. Click **Create link**

<DocScreenshot src="/screenshots/taken/task-share-dialog.png" alt="Share tasks dialog with link type, contents and filters" />

Under **Earlier links** you will find all the links you have created for this source. For each link you can:

- **Copy link**
- For a calendar link, **Add to calendar**, which opens the subscription straight in your calendar app
- **Invalidate** (after confirmation). The link then stops working. Other links stay valid. An invalid link stays in the list, marked **Invalid**

<Callout type="warn">
A share link is private, but anyone who has the link can see the tasks, even without signing in. Only share it with people who are allowed to see them, and invalidate it as soon as it is no longer needed.
</Callout>

## The shareable page [#de-deelbare-pagina]

The page shows the tasks per group, with the name, status, priority, deadline, labels and the names of the assigned colleagues for each task. There are no buttons to change anything. With a large group you see **[number] of [total]** tasks.

By default only open tasks are shown, unless you set a status filter yourself or share a view. If there is nothing to do, you see **Nothing to do right now.**

## The calendar [#de-agenda]

The calendar contains tasks with a **deadline** or a **reminder**. Tasks without a date are not included.

- Recurring reminders appear as a series, and you get a notification for each reminder
- Without a reminder, you get a notification an hour before the deadline
- Completed tasks stay visible for another two weeks, marked as completed, and then drop out
- For a view, the calendar follows the view, regardless of who the tasks are assigned to. If the person who created the link can no longer see the view, the link stops working

<Callout type="info">
In Google Calendar you also need to turn on default notifications for a subscribed calendar, otherwise the notifications do not come through.
</Callout>

## What happens next? [#wat-gebeurt-er-daarna]

- The link works straight away and keeps working until you invalidate it. Anyone with the link can see the tasks, even without signing in.
- A shareable page follows the tasks: changes in Tillor show up there.
- A calendar subscription updates itself in your calendar app, and sends a notification an hour before the deadline or at each reminder.
- If you invalidate a link, only that link stops. Other links stay valid, and the invalid link stays in the list, marked **Invalid**.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says Could not create a link">
The link was not created. Check that you have chosen a source under **Contents** and try again. The message **Could not load links.** means the list of earlier links did not open. Open the window again.
</Accordion>
<Accordion title="The page shows Nothing to do right now">
There are no tasks that match the source and the filters. A shareable page only shows open tasks by default.
</Accordion>
<Accordion title="The calendar does not show my tasks">
Only tasks with a deadline or reminder appear in the calendar. If the person who created the link can no longer see the view, the link stops working too.
</Accordion>
<Accordion title="I do not get notifications in Google Calendar">
Also turn on the default notifications for the subscribed calendar in Google Calendar.
</Accordion>
<Accordion title="I want the link to stop working">
Choose **Invalidate** next to the link and confirm at **Invalidate this link?**. If that fails, you will see **Could not invalidate the link**: try again.
</Accordion>
</Accordions>


# Filtering (/en-GB/taken/filteren)

Above the tasks is a search bar with the filter buttons next to it. Filters belong to the view: if you save them, they determine which tasks the view shows. For a filtered view, those are the tasks that match the filters. For a list, those are the manually added tasks that also match the filters.

<DocScreenshot src="/screenshots/taken/task-filter-status.png" alt="The status filter with the choices Include and Exclude and the four statuses" />

## Always-visible filters [#altijd-zichtbare-filters]

| Filter | What you choose |
|---|---|
| **Status** | One or more statuses |
| **Priority** | One or more priorities |
| **Assigned to** | One or more colleagues, or **Me** for yourself |
| **Label** | One or more labels |
| **View** | Tasks that are in another (manual) view |
| **Blocked** | **Blocked** or **Not blocked** |
| **Linked to** | The kind of record the task is attached to, such as a customer, terrain, invoice or reservation |
| **Text** | Words that the name or description does or does not contain, see below |
| **Deadline** | A period, see below |

For the filters with a list, you choose **Include** (tasks with the chosen values) or **Exclude** (tasks without those values) at the top. For **Linked to** you choose the kind of item: **Customer**, **Invoice**, **Reservation**, **Meter**, **Terrain**, **Comment**, **Conversation**, **Phone call**, **Bank transaction** or **Product**.

## Filtering by text [#filteren-op-tekst]

With **Text** you only show tasks whose name or description does or does not contain a piece of text. Upper and lower case do not matter.

1. Click **Text**
2. Choose **Contains** or **Does not contain**
3. Type the text in **Text in name or description**, for example `Verzekering vervallen:`
4. Click **Add** or press Enter

Repeat this for every text you want to add. Each text is a separate filter, so you can combine **Contains** and **Does not contain**: for example `caravan`, but not `Verzekering vervallen:`. With the cross next to a text you remove it. The button shows the text itself, or the number of texts if there are more.

<Callout>
Whether a task has to match **all** texts or **one** of them depends on the choice under [Combining several filters](#meerdere-filters-combineren). If you want to exclude several texts, leave it on **Match all filters**.
</Callout>

## Filtering by date [#filteren-op-datum]

**Deadline** works with fixed choices that move with the day, or with a custom range.

- **Overdue**, **Today**, **Tomorrow**, **This week**, **Next week**, **This month**
- **No date** (tasks without a deadline) and **Has a date**
- **Custom range**: choose a start and end date on the calendar and click **Apply range**. The end day counts in full

<DocScreenshot src="/screenshots/taken/task-filter-deadline.png" alt="The deadline filter with fixed choices and a calendar for a custom range" />

If you click a chosen option again, the filter is removed.

## Combining several filters [#meerdere-filters-combineren]

As soon as you have two or more filters, a dropdown appears:

- **Match all filters** - a task must fit every filter
- **Match any filter** - it is enough for a task to fit one of the filters

With **Clear filters** you remove all filters at once.

## Examples [#voorbeelden]

- *Everything due today that is still open*: filter **Deadline** on **Today** and **Status** on everything except **Completed**
- *Tasks I am waiting on*: filter **Status** on **Waiting for reply** and **Assigned to** on **Me**
- *Everything except the notifications about expired insurance*: filter **Text** on **Does not contain** `Verzekering vervallen:`
- *Everything around one customer*: open the customer. On the **Tasks** tab of the customer page you will find all tasks linked to that customer

## What happens next? [#wat-gebeurt-er-daarna]

- Filters on your screen narrow down what you see. Only when you save them with **Save view** do they become part of the view, so that colleagues see the same selection.
- You can also save filters on the built-in view **All**. They then apply to everyone in your organisation. For that you need the permission **Manage labels and shared views**.
- In a filtered view, tasks appear and disappear by themselves as they match the filters or not.
- The search bar is never saved.

## Problems? [#problemen]

<Accordions>
<Accordion title="I no longer see any tasks">
Check whether a filter is active, such as a status filter that excludes **Completed**, or **Match all filters** when you meant one of the filters. With **Clear filters** you start again.
</Accordion>
<Accordion title="The filter is gone after refreshing">
You had not saved it. Choose **Save view** in the **Unsaved changes** bar.
</Accordion>
<Accordion title="I cannot save the filters on All">
**Save view** is greyed out if you do not have the permission **Manage labels and shared views**, because **All** applies to the whole organisation. Ask an administrator, or create a view of your own with the same filters.
</Accordion>
<Accordion title="A colleague's task is not there">
You only see tasks you are allowed to see. A task in a colleague's personal view is invisible to you. See [Private tasks](/taken/prive-taken).
</Accordion>
<Accordion title="The Deadline filter shows nothing with a custom range">
After choosing a start and end date, click **Apply range**.
</Accordion>
</Accordions>


# Table, board and calendar (/en-GB/taken/indelingen)

You can look at the same tasks in three ways. At the top right, open **Display** to choose:

- **Layout** - **Table**, **Board** or **Calendar**. This choice only appears for saved views, not for **All**
- **Group by** - how tasks are divided into groups or columns
- **Sort by** and **Order** - **Ascending** or **Descending**
- **Type** - whether the view is a **List** or a **Filtered view**, see [Views](/taken/weergaven#twee-soorten-weergaven). This also only appears for saved views
- **Completed** - how long completed tasks stay visible

<DocScreenshot src="/screenshots/taken/task-view-display-options.png" alt="The Display menu with layout, type, group by, sort and completed tasks" />

Changes remain a proposal until you save them, see [Saving or discarding changes](/taken/weergaven#wijzigingen-opslaan-of-verwerpen).

## Hiding completed tasks [#voltooide-taken-verbergen]

Under **Completed** in the **Display** menu you decide how long a completed task stays in the view:

| Choice | What you see |
|---|---|
| **Show all** | All completed tasks (default) |
| **Hide** | No completed tasks |
| **Past day** | Tasks completed in the last day |
| **Past week** | Tasks completed in the last week |
| **Past month** | Tasks completed in the last month |

It counts from the moment the task was set to **Completed**. A comment or a new name does not change that. If you reopen a task, it is back in the view straight away. If the view already has a status filter that excludes completed tasks, that filter still applies.

## Grouping [#groeperen]

| Grouping | Result |
|---|---|
| **No grouping** | All tasks in one list |
| **Status** | One group per status |
| **Priority** | One group per priority |
| **Assigned to** | One group per colleague |
| **Label** | One group per label |
| **Customer** | One group per customer |
| **Deadline** | Groups such as **Overdue**, **Today**, **This week**, **Later** and **No deadline** |
| **Custom columns** | Columns you make yourself, only for saved views |

A task with several assigned colleagues or labels appears in the group of each of them.

## Sorting [#sorteren]

You can sort by **Manual**, **Deadline**, **Priority**, **Status**, **Name**, **Created** or **Updated**. With **Manual** you decide the order yourself by dragging cards. With the other choices the field determines the order and dragging within a column has no effect, except with custom columns.

## Table [#tabel]

The table shows one row per task. With grouping you get a block per group. Under **Columns** in the display menu you turn columns on or off: **Task**, **Status**, **Priority**, **Deadline**, **Views**, **Assigned to**, **Linked** and **Label**. The **Linked** column shows all items the task is attached to. The **Task** column is always visible.

With many tasks, Tillor first loads a part of them. Scroll down or click **Load more** for the rest.

## Board [#bord]

The board shows each group as a column, kanban style. At the top of a column, click **New task** to create a task there. It automatically gets the value of the column, such as the status or the assigned colleague.

Drag a task card to another column and the task takes over the value of that column:

- on a board by **Status**, the status changes
- on **Priority**, the priority changes
- on **Assigned to**, the assigned colleague changes
- on **Label** and **Customer**, the label or customer changes
- on **Custom columns**, the task moves to that column

On a board by **Deadline** you cannot drag cards to another column, because a deadline would have to be made up. Change the deadline in the task itself.

If a column has more tasks than are shown, you see **[number] more** at the bottom. A card that is blocked by other tasks or blocks them shows that too, for example **Blocked by 1 task**.

### Custom columns [#eigen-kolommen]

With **Custom columns** you make the columns yourself, such as *To plan*, *Ordered* and *Done*:

1. In **Display**, under **Group by**, choose **Custom columns** (or choose this already when creating)
2. On the right of the board, click **New column** and give the column a name
3. In the menu of a column, choose **Edit** to rename it or **Delete**
4. Drag columns by their title to change the order

<DocScreenshot src="/screenshots/taken/task-view-own-columns.png" alt="Board with custom columns To plan, Ordered and Done, plus New column" />

New custom columns start empty. Every task in the view is then first in **No column** until you sort it. With a list you can hide those tasks with the tick box **Show tasks without a column**. With a filtered view they stay visible, otherwise you could never sort them.

<Callout type="warn">
If you switch from **Custom columns** to another grouping and save that, the custom columns of that view are deleted, together with the position of each task in them. This cannot be undone. Tillor shows a warning about this beforehand.
</Callout>

### Assigning tasks to a list [#taken-toewijzen-aan-een-lijst]

On the board of a list, as long as there are tasks that are not in it yet, the **Assign tasks** button appears. It opens an extra column **Not in this view** with the tasks that match the filters of the view but are not in it yet. Search with **Filter tasks...** and drag a task to a column to add it to the view. Click the button again to close the column.

## Calendar [#kalender]

The calendar shows a month grid with tasks on their **deadline**. The week starts on Monday and the days follow your organisation's time zone. Tasks without a deadline are not in the calendar.

- With the arrows you go to the previous or next month, with **Today** you jump back to the current month
- Per day you see at most three tasks. Click **+[number] more** to see the rest of the day
- Click a task to open its details
- Drag a task to another day to move the deadline. The time stays the same, only the day changes
- Completed tasks are struck through, appear below the open tasks of that day and cannot be dragged

Grouping has no effect in the calendar: all tasks are in the same grid.

## What happens next? [#wat-gebeurt-er-daarna]

- Your changes in **Display** are first a proposal on your screen. Only after **Save view** do they apply to everyone who sees the view.
- If you drag a card to another column, the task itself changes. On a board by **Status** the status changes, and colleagues see that straight away.
- Dragging a card in a calendar moves the deadline to that day. The time stays the same.

## Problems? [#problemen]

<Accordions>
<Accordion title="I cannot drag a card to another column">
On a board by **Deadline** that is not possible, because Tillor would have to make up a deadline. Change the deadline in the task. In a calendar you drag tasks to another day, except completed tasks.
</Accordion>
<Accordion title="Tillor says the task could not be moved">
You see **Failed to move task**. The card jumps back to its old place. Try again.
</Accordion>
<Accordion title="The Layout or Type choice is missing">
Those only appear for saved views, not for **All**.
</Accordion>
<Accordion title="A task is not in the calendar">
The calendar shows tasks on their deadline. A task without a deadline is not in it.
</Accordion>
<Accordion title="My tasks are in No column">
With new custom columns, all tasks start in **No column** until you sort them. Drag them to the right column.
</Accordion>
<Accordion title="My custom columns are gone">
You switched to another grouping and saved that. Tillor then deletes the custom columns, and this cannot be undone. Tillor warns you about this beforehand.
</Accordion>
</Accordions>


# Overview (/en-GB/taken)

With the task system you keep track of what needs to be done in your park and by whom. A task can have a deadline, a reminder, one or more assigned colleagues or groups, labels, attachments, subtasks, time spent and linked customers, terrains, invoices, reservations, meters, conversations or bank transactions.

You look at tasks through **views**. A view is a saved way of looking at your tasks, for example *Open tasks*, *My tasks* or *Maintenance*. Each view appears as a tab at the top of the page.

## Where to find tasks [#waar-vind-je-taken]

- **Tasks** in the side menu: the main page with all your views
- **Dashboard**: the card **Tasks for you** shows the tasks assigned to you, or your favourite view
- **Customers > [customer] > Tasks**: all tasks linked to a customer
- **Open tasks**: a block on the page of a customer, reservation, invoice, terrain and meter

<DocScreenshot src="/screenshots/taken/tasks-board.png" alt="Tasks page with tabs per view and a board per status" />

At the top are the views as tabs. Below them are the search bar and the filters, and on the right the buttons **Display**, **Follow** and share. Below that you see the tasks, here as a board per status. Hover over the ℹ markers for an explanation.

## How does it all fit together? [#hoe-hangt-dit-samen]

A task is one thing, and views are ways of looking at tasks. Tasks are created by colleagues or by automations. An automation can also wait for a task.

```mermaid
flowchart LR
  A["A colleague creates a task<br/>on the tasks page or from a customer, invoice or meter"] --> T["Task"]
  B["An automation creates a task<br/>step Create task, in the name of Workflow"] --> T
  T --> L["List<br/>only shows tasks you add to it yourself"]
  T --> G["Filtered view<br/>shows every task that matches the filters"]
  L --> Z["The visibility of the view<br/>determines who sees the task"]
  T -- "A colleague chooses a button on the task" --> W["The automation stops waiting<br/>and continues"]
  T -- "Status or assignment changes" --> S["An automation can start on that"]
```

- If you put a task in a view, nothing changes about the task itself. Only the view gets it added.
- A filtered view does not take tasks out: they appear or disappear by themselves as they do or do not match the filters.
- A task that an automation creates is an ordinary task. If it has choice buttons (step **Ask for a decision**), the automation waits until someone chooses a button. See [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen) and [Tasks in automations](/automatiseringen/acties/taken).

## Getting started [#snel-aan-de-slag]

1. Open **Tasks** in the side menu
2. Click **New view**. Fill in a **Name** and choose what you want under **Visibility**, **Contents**, **Columns** and **Start with**. Then click **New view** at the bottom of the dialog
3. At the top of a column, click **New task**, give the task a name and click **Create**
4. Click a task to open its details: status, priority, deadline, assigned colleagues and more
5. Tick the box on the left of a task as soon as it is done

<DocScreenshot src="/screenshots/taken/task-view-create-dialog.png" alt="New view dialog with name, visibility, contents, columns and start filter" />

Without views of your own, you can always fall back on the built-in view **All**, which shows all tasks you are allowed to see. Filters saved on **All** apply to the whole organisation.

## Statuses [#statussen]

| Status | Meaning |
|---|---|
| **Pending** | The task is planned but work has not started yet |
| **In Progress** | The task is being actively worked on |
| **Waiting for reply** | You can only continue when someone else, such as a customer or supplier, has done or answered something |
| **Completed** | The task is finished |

This is what the same kind of task looks like before and after ticking it off. Above is an open task, below a completed one: the title is struck through and the status is **Completed**.

<DocScreenshot src="/screenshots/taken/task-card-open.png" alt="Before: an open task with the status In Progress" />

<DocScreenshot src="/screenshots/taken/task-card-done.png" alt="After: a completed task with a struck-through title and the status Completed" />

A completed task sinks to the bottom in a manually sorted list or column. If you set a parent task to **Completed**, the open subtasks are completed too. If you then reopen the task, the subtasks stay completed.

A view can hide completed tasks after a while, see [Hiding completed tasks](/taken/indelingen#voltooide-taken-verbergen).

## Priorities [#prioriteiten]

A task has the priority **Low**, **Medium**, **High** or **Urgent**.

## Sections [#onderdelen]

<Cards>
  <Card
    title="Views"
    href="/taken/weergaven"
    description="Create, share, duplicate and follow lists and filtered views"
  />
  <Card
    title="Table, board and calendar"
    href="/taken/indelingen"
    description="Choose how your tasks are shown, group and sort"
  />
  <Card
    title="Filtering"
    href="/taken/filteren"
    description="Find tasks by status, deadline, customer, linked item and more"
  />
  <Card
    title="Task details"
    href="/taken/taakdetails"
    description="Everything you can record in a task, from subtasks and time spent to printing"
  />
  <Card
    title="Private tasks"
    href="/taken/prive-taken"
    description="Who sees a task depends on the views it is in"
  />
  <Card
    title="Labels"
    href="/taken/labels"
    description="Manage labels and have a deadline set automatically"
  />
  <Card
    title="Notifications"
    href="/taken/meldingen"
    description="Reminders, deadlines and the daily digest of a view"
  />
  <Card
    title="Share tasks"
    href="/taken/delen"
    description="Create a read-only page or a calendar subscription"
  />
  <Card
    title="Tasks on other pages"
    href="/taken/taken-op-andere-paginas"
    description="Create tasks from customers, invoices, conversations and more"
  />
</Cards>

<Callout type="info" title="Good to know">
- There are no separate permissions for tasks. Anyone who works in Tillor can create and edit tasks. Which tasks you get to see depends on the views they are in. See [Private tasks](/taken/prive-taken)
- A new task can have up to 50 subtasks. Subtasks have only one level
- If you set a task to **Completed**, the open subtasks are completed too
- Anyone who follows a view gets a summary every morning at 07:00, with at most 15 tasks per list
- A running timer pauses after ten minutes without mouse or keyboard activity
- A label with a **Deadline target (days)** automatically gives tasks without a deadline a deadline
- A task you delete cannot be restored
</Callout>

## Terms [#begrippen]

- **Task**: a job you keep track of, with status, priority, deadline and optionally assigned colleagues
- **View**: a tab on the tasks page with its own way of showing tasks, see [Views](/taken/weergaven)
- **List**: a view that only shows tasks you add to it yourself
- **Filtered view**: a view that shows every task that matches the filters
- **Subtask**: a part of a task, as a checklist
- **Blocker**: a task that must be finished before another task can start
- **Workflow**: the user in whose name an [automation](/begrippen#automatisering) creates tasks

More terms are in the [glossary](/begrippen).


# Labels (/en-GB/taken/labels)

With labels you give tasks a category, for example *Maintenance*, *Complaints* or *Season*. You can filter and group by labels. A label has a name, a colour and optionally a description.

## Managing labels [#labels-beheren]

Go to <UIPath>Settings > Task labels</UIPath>. You see that page if you are allowed to view or edit your organisation's general settings. The overview has the columns **Label**, **Description** and **Tasks** (the number of tasks with that label).

<DocScreenshot src="/screenshots/taken/task-labels-settings.png" alt="Settings, Task labels page with the labels Administration, Maintenance and Reception" />

- **New label** creates a label with a **Name**, **Description**, **Colour** and optionally a **Deadline target (days)**
- **Edit label** changes those details later
- **Delete label** removes the label and first shows how many tasks it is on. The label disappears from all those tasks

You can also create a label while editing a task: type the name in the **Labels** field and choose **Create [name]**.

## Setting a deadline automatically [#een-deadline-automatisch-instellen]

<DocScreenshot src="/screenshots/taken/task-label-dialog.png" alt="Create label dialog with name, description, colour and deadline target" />

For a label you can fill in the **Deadline target (days)**, for example *7*. A task without a deadline that gets that label then gets a deadline itself: that many days later, counted from the moment the task was created or the label was added.

- This happens when you create a task with the label, or when you add the label later
- If the task already has a deadline, it stays as it is
- If a task has several labels with a target, the shortest number of days applies
- If you leave the field empty, the label does not set a deadline

This is useful for labels such as *Complaint* (within 2 days) or *Follow up quote* (within 7 days).

## What happens next? [#wat-gebeurt-er-daarna]

- You can give a new label to tasks straight away, in the task itself and in the quick menu.
- A label with a **Deadline target (days)** automatically gives tasks without a deadline a deadline from that moment on.
- If you delete a label, it disappears from all tasks it was on. The tasks remain.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see the Task labels page">
You are not allowed to view your organisation's general settings. Ask an administrator to change your permissions.
</Accordion>
<Accordion title="Tillor says Failed to create label">
Fill in a **Name** (at most 50 characters) and try again. When editing and deleting, the messages are **Failed to update label** and **Failed to delete label**.
</Accordion>
<Accordion title="My task did not get a deadline from the label">
A deadline from the label only goes on tasks without a deadline. If the task already has one, it stays. With several labels with a target, the shortest number of days applies.
</Accordion>
</Accordions>


# Notifications (/en-GB/taken/meldingen)

Tillor keeps you up to date about tasks by email and push notifications.

## Reminders and deadlines [#herinneringen-en-deadlines]

If a task has a **Reminder** or **Deadline**, you choose in the detail window under **Notifications** whether you want an **Email** and/or **Push notification**. Both are on by default. If you turn both off, nobody gets a notification for that task.

- A reminder goes off at the set time, with the title *Task reminder*
- A deadline notification goes off as soon as the deadline is reached and the task is not yet completed
- Completed tasks no longer give a reminder or deadline notification
- A recurring reminder goes off at every repeat, until the task is completed or the schedule ends

The notification goes to the assigned colleagues, including the members of an assigned group. If nobody is assigned, it goes to the creator of the task. The email shows a preview of the task, with the status and a button to open it.

## Assigning, unassigning and completing [#toewijzen-ontkoppelen-en-voltooien]

- If a task is assigned to you, also via a group you are in, you get a notification (**New task assigned**). If you assign a task to yourself, you get no notification
- If someone removes you from a task, you get a notification that the task has been unassigned (**Task unassigned**)
- When a task is completed, the assigned colleagues and the creator get a notification, except the person who completed the task. The notification is sent with a delay of about a minute. If someone reopens the task within that time, it is not sent

## Following a view [#een-weergave-volgen]

With **Follow** (top right of a saved view) you get an email every morning at 07:00 with a summary of that view. The email has the subject line *Daily digest* with the name of the view, and contains three lists:

- **Overdue** - open tasks whose deadline has passed
- **Due today** - open tasks that are due today
- **Changed since the last digest** - open tasks that have been changed since your previous digest

Each list shows at most 15 tasks with the deadline. At the bottom is the **Open view** button, which jumps straight to the view.

- If all three lists are empty, you get no email that day
- The button changes to **Following**. Click it to stop following. You can follow any view you can see, including colleagues' views
- If you lose access to the view, for example because the owner makes it private or deletes it, you automatically stop following
- You only see tasks you are allowed to see yourself

<Callout type="info">
You cannot follow the built-in view **All**, because it is not a saved view.
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not get a reminder or deadline notification">
Check in the task under **Notifications** whether **Email** or **Push notification** is on. A notification goes to the assigned colleagues, or to the creator if nobody is assigned. Completed tasks no longer give a notification.
</Accordion>
<Accordion title="I get no notification when I assign a task to myself">
That is correct. You only get a **New task assigned** notification when someone else assigns the task to you.
</Accordion>
<Accordion title="I do not get the daily digest">
Either you are not following the view (the **Follow** button should show **Following**), or there is nothing in **Overdue**, **Due today** and **Changed since the last digest**. In that case we do not send an email that day. You also stop following automatically if you are no longer allowed to see the view.
</Accordion>
<Accordion title="Tillor says Could not update following">
The change was not saved. Click **Follow** again.
</Accordion>
</Accordions>


# Private tasks (/en-GB/taken/prive-taken)

A task is private if it is only in personal views. You do not need to set anything up for that: the views a task is in determine who sees it.

## The rules [#de-regels]

| Where the task is | Who sees it |
|---|---|
| In no view at all | All users of the organisation |
| In at least one view that is **Public** | All users of the organisation |
| Only in personal views (**Only you** or **Shared**) | The creator of the task, the assigned colleagues and groups, and the owner and the chosen people and groups of those views |

Subtasks follow their parent task. A task you are not allowed to see appears nowhere: not in lists, search results, filters, the dashboard, on a customer, in the calendar or in notifications, and you cannot open it via a link either.

## Example [#voorbeeld]

Jan creates the personal view *My ideas* with visibility **Only you**. He adds the task *Request quote for new barrier* to that list.

- Only Jan sees the task. His colleagues do not see it anywhere
- Jan assigns the task to Piet. Now Piet sees the task too, even though he has never seen Jan's view
- Jan shares *My ideas* with Els (**Shared**). Now Els sees the task too
- Jan adds the task to the view *Maintenance*, which is **Public**. From now on the whole team sees the task
- If Jan removes the task from *Maintenance* again, and it is in no other public view, it is private again

Had Jan put the task in no view at all, everyone would have seen it.

## Who decides the visibility of a view [#wie-bepaalt-de-zichtbaarheid-van-een-weergave]

Only the owner of a personal view can change who the view is shared with, or make it **Public**. A colleague you share the view with can edit tasks in the view, but cannot change the visibility and cannot delete the view either. See [Views](/taken/weergaven#wie-ziet-een-weergave).

<Callout type="warn">
Adding a private task to a public view makes it visible to everyone. Tillor asks you to confirm that first with **Make this task public?**. You can then choose **Keep private** or **Make public**. The same question appears if you remove the task from its last public view. If you make a personal view that contains tasks **Public**, those tasks become visible to everyone without a separate question.
</Callout>

## Tips [#tips]

- If you want to hand over a private task, assign it to a colleague or share the view with that colleague
- A task counts as "in a view" as soon as you add it to a list or put it in a custom column of the view. Merely showing it through a filter does not make it part of the view
- Notifications about a private task, such as a deadline, only go to people who are allowed to see the task

## Problems? [#problemen]

<Accordions>
<Accordion title="A colleague does not see my task">
The task is only in personal views. Assign it to the colleague, share the view with them, or put the task in a public view.
</Accordion>
<Accordion title="Tillor asks Make this task public?">
You are adding a private task to a public view, or removing it from its last public view. Choose **Keep private** or **Make public**.
</Accordion>
<Accordion title="I no longer see a task I still had yesterday">
Perhaps the task has been linked to another view, or the view it was in is no longer visible to you. Ask the creator or the owner of the view.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Views" href="/taken/weergaven" />
  <Card title="Task details" href="/taken/taakdetails" />
</Cards>


# Task details (/en-GB/taken/taakdetails)

In a task's detail window you record everything: who does it, when it is due, how much time is in it and what it is linked to. Click a task to open the window. On the left are the name, description and parts such as subtasks and comments. On the right are the properties such as status, priority and deadline. Changes to an existing task are saved straight away. Only the description is saved by you, with **Save**.

<DocScreenshot src="/screenshots/taken/task-detail-dialog.png" alt="Task window with description, subtasks, comments and, on the right, the properties, custom fields, linked items and attachments" />

You can also open a task directly with a link. Copy it from the three-dot menu at the top right of the window, see [The task menu](#het-menu-van-de-taak).

## Creating a task [#een-taak-aanmaken]

You create tasks in several places: at the top of a board column (**New Task**), in the **Tasks for you** card on the dashboard, on the customer page, or from a conversation, invoice or other item, see [Tasks on other pages](/taken/taken-op-andere-paginas).

1. Click **New Task**
2. Enter a **Name**. The rest is optional
3. Optionally add subtasks under **Add a subtask**: type a name and press Enter. You can add up to 50
4. Click **Create**, or press Cmd or Ctrl together with Enter

<DocScreenshot src="/screenshots/taken/task-create-dialog.png" alt="New Task dialog with a name and two subtasks" />

At the top of the window is the view the task will go in. If you create the task from a board column, it automatically gets that view and column. You can choose another one or remove the view.

You are filled in as the assignee. If you remove yourself and choose nobody, the task has no assignee. You add blockers and time spent after the task has been created.

## Properties [#eigenschappen]

- **Status** and **Priority** - see the [overview](/taken#statussen)
- **Assigned to** - one or more colleagues or [groups](/gebruikers/groepen). Search with **Search people or groups...**. If you assign a group, the task applies to everyone who is in the group at that moment
- **Customers** - link one or more customers with **Add a customer**
- **Labels** - see [Labels](/taken/labels). You create a missing label straight away by typing its name and choosing **Create [name]**
- **Deadline** - the final date, with the time. If the deadline has passed, the relative time turns red
- **Reminder** - a date and time at which you want a notification, optionally repeating
- **Notifications** - as soon as a reminder or deadline is set, you choose whether you want an **Email** and/or **Push notification**. Both are on by default
- **Created by** - who created the task
- **Custom fields** - fields that your organisation has added to tasks itself. Changes are saved straight away. See [Custom fields](/eigen-velden)
- **View** - click the name of the view at the top left to choose which lists the task is in and in which column. For a filtered view you only choose a column
- **Private** - if there is a padlock with **Private**, the task only appears in personal views, see [Private tasks](/taken/prive-taken)

A task can also have a **Description**. It supports Markdown for formatting.

## Repeating reminders [#herhalende-herinneringen]

A reminder can repeat itself until the task is completed:

1. First set a **Reminder** (date and time)
2. Click the repeat field below it (**Does not repeat** by default)
3. Choose **Daily**, **Every weekday (Mon – Fri)**, **Weekly**, **Monthly**, **Yearly** or **Custom…**

With **Custom…** you put together your own schedule:

- **Repeat every** - a number of days, weeks, months or years
- **Repeat on** - for a weekly schedule, the weekdays on which the reminder may come
- **Ends** - **Never**, **On date** or **After** a number of times

If a reminder falls on a day you have excluded, it moves on to the next permitted day without a notification. The repetition stops as soon as the task is **Completed** or the schedule ends.

## Linked items [#gekoppelde-items]

Under **Linked items** you see what the task is attached to. You can link several of each kind: terrains, invoices, reservations, meters, phone calls, bank transactions, products and conversations from the inbox. A task can also be linked to a comment. You create a task about a bank transaction from the transaction's menu under **Bank transactions** with **Create task**. You create a task about a product, such as checking the ledger account, on the product page via the **⋯** menu with **Create task**; the product's open tasks appear at the top of that page.

You link an extra item with the plus next to **Linked items** (tooltip **Link item**). Search for a customer, terrain, meter, invoice, reservation or product. If the chosen item belongs to a customer, Tillor asks **Also link [customer]?**:

- **Link both** - the task also appears on the customer
- **Only this item** - the customer is not linked to the task

With **Unlink** you remove a link again. Linked tasks that are still open appear on the item's page under **Open tasks**.

## Attachments [#bijlagen]

Under **Attachments** you add files to the task. Click the plus, or paste a file with Cmd or Ctrl and V anywhere in the window.

## Subtasks [#subtaken]

A task can have subtasks, a checklist in the detail window. There is only one level: a subtask cannot have subtasks of its own.

1. Open the parent task, or fill them in while you create a task
2. Under **Add a subtask**, type a name and press Enter
3. Tick a subtask to set it to **Completed**. Tick it again to set it back
4. Click the name to rename it, or the bin to delete it
5. Drag a subtask by its handle to change the order. With **Add description** you can also give a subtask a description

With a new task, the subtasks are created together with the task, in the order in which you entered them. Subtasks do not appear as separate cards on boards, in tables or in the calendar. On the task you see a counter such as **2/5**. If you set the parent task to **Completed**, all open subtasks are completed too. The reverse is not required: you can finish the parent task while subtasks are still open.

## Blockers and dependencies [#blokkades-en-afhankelijkheden]

Sometimes a task can only start or finish when another one is done. You record that in the detail window:

- **Blocked by** - tasks that must be finished first. Add them with **Add blocking task**
- **Blocks other tasks** - tasks that are waiting for this task. Add them with **Add blocked task**

For each group you see how many tasks are still open (for example **2 still open**). Search for tasks with **Search tasks...** and remove a link with **Remove link**. On the task card there is a line under the name such as **Blocked by 1 task**. You can filter on blocked tasks, see [Filtering](/taken/filteren).

A blocker does not stop you. If you try to tick off a blocked task, Tillor asks **Complete a blocked task?** and only completes it if you choose **Complete anyway**.

You also add a blocker via the three-dot menu at the top right of the window, with **Add blocking task** and **Add blocked task**.

## Time spent [#bestede-tijd]

Next to **Time spent** in the detail window is the total. Click it to log time.

<DocScreenshot src="/screenshots/taken/task-time-popover.png" alt="Time spent with the Start button, an input field for a manual entry and the entries of colleagues" />

You have two ways:

- A **timer**. Click **Start**, work on the task and click the stop button when you are done. The time is put on the task, seconds included
- **Filling it in afterwards**. Enter the duration, for example **1:30**, **90** (minutes), **1h 30m** or **1.5h**. All four mean an hour and a half. Optionally add a note under **What did you do? (optional)** and click **Log**

The time is logged on today's date. In the list you see for each entry who did it, the date, the note and the duration. Colleagues see each other's entries, but you can only delete your own entries, using the bin that appears when you hover over the line.

### The timer [#de-timer]

- A running timer keeps going when you go to another page. It then appears as a small card at the bottom right, with buttons to pause (**Pause**), resume (**Resume**), **Check in** and stop (**End**). Click the name of the task to go back
- With **Check in** you save the stretch so far, with a short note about what you were working on, and the timer then keeps running
- You can only track time on one task at a time. While your timer is running, **Start** is disabled on other tasks
- If you use no mouse or keyboard for ten minutes, the timer pauses at the last moment you were active
- Colleagues see in the task window that you are working (**In progress**) or paused (**Paused**). That time only counts towards the total once it has been saved

## Comments and activity [#opmerkingen-en-activiteit]

At the bottom of the window is the **Comments** section. With **Add comment** you write a comment. You can mention colleagues in a comment so that they get a notification. Below that is the **activity**: a timeline of creation and changes, showing for a change what it was before and after.

## The task menu [#het-menu-van-de-taak]

At the top right of the window is a menu with three dots.

<DocScreenshot src="/screenshots/taken/task-dialog-menu.png" alt="Task menu with add blockers, Print, Copy link and Delete" />

- **Add blocking task** and **Add blocked task** record a dependency
- **Print** has three choices. **Print (A4)** opens your browser's print dialog with a PDF of the task. **Send to A4 printer** and **Send to thermal printer (POS)** send the task to your printer, for example a receipt printer. You can only choose these two if your organisation has a [connector](/connector) with a printer, see [Printer](/printer)
- **Copy link** copies a link that opens the task directly. Whoever opens the link must be allowed to see the task
- **Delete** is at the bottom, see [Deleting a task](#een-taak-verwijderen)

The printout shows the name, status, priority, deadline and description, and under **Linked items** the customers, invoices, reservations, terrains and meters the task is attached to. If the task has blockers, the tasks that block it and the tasks that it blocks itself are included. A group without items is left out.

## Tasks with choice buttons [#taken-met-keuzeknoppen]

Some tasks, for example from an [automation with the step Ask for a decision](/automatiseringen/logica#vraag-om-een-beslissing), ask for a decision. Instead of a tick there are buttons on the task, with **Choose an action to finish this task** above them. You click a button and the task is finished.

- If the choice requires a reason, Tillor first opens a window with **Why this choice?** where you enter a note
- If the choice requires confirmation, Tillor first shows a window. A choice that has been made cannot be undone from the task
- After that, the task shows which choice was made and by whom
- Whoever is assigned to the task and an administrator can choose. If nobody is assigned, anyone who can see the task can choose

This is how the task and the automation are connected:

```mermaid
flowchart TD
  A["De automatisering bereikt de stap<br/>Vraag om een beslissing"] --> B["Tillor maakt een taak met jouw knoppen<br/>en de automatisering wacht"]
  B --> C{"Een collega kiest een knop"}
  C -- "Een optie" --> D["De taak staat op Voltooid<br/>de automatisering gaat via die optie verder"]
  C -- "Niemand kiest binnen de wachttijd" --> E["De automatisering gaat via Verlopen verder<br/>de taak blijft bestaan"]
  C -- "De taak wordt verwijderd" --> E
```

A task that was created by an automation and can only be finished by the flow shows the text **Finished by its automation** instead of a tick. You cannot complete it then, and it has no **Delete** in the menu.

## Changing the status quickly and ticking off [#status-snel-wijzigen-en-afvinken]

Without opening the window you can:

- Tick the box to the left of the task name to set the task to **Completed**. If you untick it, it goes back to **In Progress**
- Click the three dots on the task card, or right-click the card, for a quick menu with **Edit**, **Status**, **Priority**, **Reminder**, **Deadline**, **Labels**, **Views** and **Delete**. **Labels** only appears if there are labels, and **Views** only if there are lists to which you add tasks yourself

<DocScreenshot src="/screenshots/taken/task-actions-menu.png" alt="Quick menu of a task card" />

## Deleting a task [#een-taak-verwijderen]

Choose **Delete** in the task's quick menu, or in the three-dot menu in the task window, and confirm. This cannot be undone and any subtasks disappear with it. The deletion is recorded in the [activity log](/activiteitenlog).

For a task that only an automation may finish, **Delete** is not in the menu. If such a task is deleted in some other way, the automation that was waiting for it to finish fails.

## What happens next? [#wat-gebeurt-er-daarna]

- Changes to an existing task are saved straight away. Only the description is saved by you, with **Save**.
- If you assign the task, that colleague (or the members of the group) gets a notification. See [Notifications](/taken/meldingen).
- If you set the task to <Status tone="success">Completed</Status>, open subtasks are completed too and the assigned colleagues and the creator get a notification, except you. The task sinks to the bottom in a manually sorted list.
- A reminder or deadline gives a notification until the task is completed.
- A task that was created by an [automation](/automatiseringen/acties/taken) can itself also start an automation, for example on a status change or when someone chooses a choice button.
- Deleting cannot be undone. The deletion is in the [activity log](/activiteitenlog).

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor asks Complete a blocked task?">
The task is still waiting for one or more unfinished tasks (see **Blocked by**). Finish those tasks first, or choose **Complete anyway**.
</Accordion>
<Accordion title="I see a text instead of a tick">
With **Finished by its automation** you cannot complete the task yourself. The automation finishes it. If the task has buttons under **Choose an action to finish this task**, you click a button.
</Accordion>
<Accordion title="I cannot use the buttons on a task">
Whoever is assigned to the task and an administrator can choose. If nobody is assigned, anyone who can see the task can choose. If you get the error **Could not save the choice**, try again.
</Accordion>
<Accordion title="The timer's Start button is grey">
Your timer is already running on another task. You can only track time on one task at a time. Stop that timer first.
</Accordion>
<Accordion title="My timer stood still while I was working">
After ten minutes without a mouse or keyboard, the timer pauses at the last moment you were active. Use **Resume** to carry on.
</Accordion>
<Accordion title="Logging time fails">
Enter a duration that Tillor understands, such as **1:30**, **90**, **1h 30m** or **1.5h**. If it still fails, you see the message **Could not log time** and you try again. You can only delete your own entries.
</Accordion>
<Accordion title="Printing to the printer is not possible">
You can only choose **Send to A4 printer** and **Send to thermal printer (POS)** if your organisation has a connector with a printer. **Print (A4)** always works. If something goes wrong, you see the message **Could not generate the task PDF**.
</Accordion>
<Accordion title="Tillor says Failed to update task">
The change has not been saved. Try again or refresh the page.
</Accordion>
<Accordion title="I cannot delete a task">
For a task that only an automation may finish, **Delete** is not in the menu. Otherwise, any colleague who can see the task can delete it.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Views" href="/taken/weergaven" />
  <Card title="Labels" href="/taken/labels" />
  <Card title="Tasks in automations" href="/automatiseringen/acties/taken" />
</Cards>


# Tasks on other pages (/en-GB/taken/taken-op-andere-paginas)

Tasks do not stand on their own. You create them from the item they are about, and you see them there too.

## Creating a task from another item [#een-taak-maken-vanuit-een-ander-item]

The task is automatically linked to the item. If a customer is involved, you can link that customer to it as well. The task is assigned to you by default.

| Where | Button |
|---|---|
| Customer page | **Create task** in the customer's actions menu |
| Invoice | **Create task** in the actions menu |
| Meter | **Create task** in the actions menu |
| Reservation | **Create task** |
| Terrain | **Create task** |
| Conversation in the inbox | **Create task** |
| Phone call | **Create task** |
| Comment | The task icon next to the comment (tooltip **Create a task from this comment**) |
| Bank transaction | **Create task** in the transaction's actions menu under <UIPath>Administration > Bank transactions</UIPath> |

## A follow-up reminder on a comment [#een-opvolgherinnering-bij-een-opmerking]

A comment also has a clock so that you (or the colleagues mentioned) are reminded to follow the comment up. With it you create a task such as *Follow up on this comment* or *Check whether [name] has picked this up*. If you later mark the comment as handled, that follow-up task is completed automatically.

## Open tasks on an item [#openstaande-taken-bij-een-item]

On the page of a customer, reservation, invoice, terrain and meter there is an **Open tasks** block with the tasks that are not yet completed and are attached to that item. If there are no open tasks, the block does not appear.

On the page <UIPath>Customers > [customer] > Tasks</UIPath> you find all of the customer's tasks. You open it via the **Tasks** tab on the customer page. Completed tasks are collapsed under **Completed tasks**, with the number next to it.

<DocScreenshot src="/screenshots/taken/customer-tasks.png" alt="Tasks tab on a customer page with New Task and the customer's tasks" />

## On the dashboard [#op-het-dashboard]

The **Tasks for you** card shows the tasks assigned to you. With the star you choose a favourite view that you want to see there instead, see [Views](/taken/weergaven#een-favoriete-weergave-voor-het-dashboard). You can also create a task there directly or share the tasks.

## What happens next? [#wat-gebeurt-er-daarna]

- The task is attached to the item you created it from. You see it under **Linked items** in the task.
- As long as the task is not completed, it appears in the **Open tasks** block on the page of that item and of the linked customer.
- A follow-up task on a comment is completed by itself when you mark the comment as handled.

## Problems? [#problemen]

<Accordions>
<Accordion title="I do not see Create task">
On some pages the button is in the actions menu, such as for a customer, invoice or meter. Look for the three dots there.
</Accordion>
<Accordion title="The Open tasks block is missing">
The block only appears if there are still unfinished tasks attached to the item.
</Accordion>
<Accordion title="Tillor says Failed to create task">
The task has not been saved. Enter a name and try again.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Task details" href="/taken/taakdetails" />
  <Card title="Views" href="/taken/weergaven" />
</Cards>


# Views (/en-GB/taken/weergaven)

At the top of the **Tasks** page is a row of tabs. Each tab is a view. The first tab, **All**, is built in: it shows every task and you cannot edit, move or delete it. You can, however, save filters and view settings on it for the whole organisation. You create all the other views yourself.

<DocScreenshot src="/screenshots/taken/tasks-board.png" alt="Tabs with views at the top of the tasks page" />

## Two kinds of views [#twee-soorten-weergaven]

When creating a view, you choose the kind under **Content**.

| Kind | What it does |
|---|---|
| **Filtered view** | Shows every task that matches the filters, like a saved search. New tasks that match appear by themselves |
| **List** | Shows only the tasks that you add to it yourself |

A list is handy for a fixed collection, for example *Season preparation*. A filtered view is handy for everything that matches a rule, for example *All urgent tasks waiting for the customer*.

You can change the kind later in **View** (top right) under **Type**. You cannot do that for **All**. If you convert a list to a filtered view, the tasks you added to it by hand are detached from it. Tillor asks you to confirm that first, because it cannot be undone.

## Creating a view [#een-weergave-aanmaken]

1. Click **New View**, to the right of the tabs
2. Enter a **Name** and optionally a **Description**
3. Under **Visibility**, choose who sees the view: **Public**, **Only you** or **Shared**. With **Shared**, you choose the colleagues and groups under **Share with**
4. Under **Content**, choose a **Filtered view** or a **List**
5. Under **Columns**, choose how the tasks are arranged: **Custom columns**, **Status**, **Assigned to** or **No grouping**
6. Under **Start with**, choose a starting filter: **All tasks**, **Open tasks** or **My tasks**
7. Click **New View** at the bottom of the dialog

<DocScreenshot src="/screenshots/taken/task-view-create-dialog.png" alt="New View dialog" />

By default the view is set to **Public**, **Filtered view**, **Status** and **Open tasks**. If you choose **No grouping**, you get a table. With the other choices you start with a board. You adjust that later, see [Table, board and calendar](/taken/indelingen).

A filtered view that is set up as a table looks like this. The filters are above the table and have already been saved here.

<DocScreenshot src="/screenshots/taken/task-view-filtered.png" alt="Filtered view Urgent tasks as a table, with filters on priority and status" />

## Who sees a view [#wie-ziet-een-weergave]

| Choice | Who sees the view |
|---|---|
| **Public** | All users of the organisation (an organisation view) |
| **Only you** | Only you (a personal view). The tab has a padlock |
| **Shared** | You and the colleagues and groups you choose under **Share with**. The tab has an icon of several people |

Under **Share with** you choose people and groups from the same list. A [group](/gebruikers/groepen) counts as it is made up at that moment: whoever joins the group later also sees the view, and whoever leaves the group no longer sees it.

Only the owner of a personal view can change who it is shared with or make it visible to everyone. Colleagues you share the view with can work in it, but cannot decide who else sees it and cannot delete it either. If you make a view **Public**, the list of chosen people and groups is dropped.

<Callout type="warn">
The visibility of a view also determines who sees the tasks in that view. Read [Private tasks](/taken/prive-taken) before you put tasks in a personal view.
</Callout>

## Editing, duplicating or deleting a view [#een-weergave-bewerken-dupliceren-of-verwijderen]

Right-click the view's tab and choose:

- **Edit** - change the name, description, visibility and columns. Filters, sorting and layout stay as they were saved. You only choose **Content** and **Start with** when creating; you change the kind later in **View**
- **Duplicate** - makes a copy named *[name] (copy)* and opens it straight away
- **Delete** - after confirmation the view disappears. The tasks themselves remain and only lose this view

Drag the tabs to change the order. The new order is saved straight away.

## Saving or discarding changes [#wijzigingen-opslaan-of-verwerpen]

If you change filters or view settings, they are first only on your screen. A bar appears at the top right with **Unsaved changes** and two buttons:

- **Save view** keeps the changes in the view
- **Discard** puts everything back to the saved version

On the built-in view **All** you save the changes for everyone in your organisation, just like for a public view. For that you need the permission **Manage labels and shared views**. Without that permission you can only **Discard** the changes on **All**.

The search bar (**Search tasks...**) is never saved with the view: it only narrows what you see now.

## A favourite view for the dashboard [#een-favoriete-weergave-voor-het-dashboard]

<DocScreenshot src="/screenshots/taken/dashboard-tasks-card.png" alt="Dashboard card Tasks for you with the buttons for favourite view and share" />

On the dashboard, the **Tasks for you** card shows the tasks assigned to you by default. You can link a view to it instead:

1. Click the star at the top right of the card
2. Choose a view from the list. Choose **Tasks for you** to go back to your own assigned tasks

You can have one favourite view at a time, and it only applies to you. If the view is later deleted or is no longer visible to you, the dashboard shows your own tasks again.

## Following a view [#een-weergave-volgen]

With the **Follow** button at the top right you receive an email every morning with what needs attention in that view. How it works is described under [Notifications](/taken/meldingen#een-weergave-volgen).

## What happens next? [#wat-gebeurt-er-daarna]

- The new view appears as a tab at the top of the tasks page. A filtered view immediately shows all tasks that match, and new tasks that match are added by themselves.
- With **Public**, all users of your organisation see the view. With **Only you**, only you see it, and with **Shared**, you and the chosen colleagues and groups.
- If you delete a view, the tasks remain. They only lose that view.
- If you convert a list to a filtered view, the tasks you added to it by hand are detached.
- A view you follow sends you a summary every morning. See [Notifications](/taken/meldingen#een-weergave-volgen).

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says the view could not be created">
You see **Failed to create view**. Check that you have entered a **Name** and try again. If it still does not work, check that your internet connection is fine. When duplicating, the message is **Could not duplicate the view** and the same applies.
</Accordion>
<Accordion title="I cannot edit or delete the All tab">
**All** is built in and shows every task you are allowed to see. Its name, position and visibility are fixed. You can, however, save filters and view settings on it, for the whole organisation. Create a view of your own if you want a selection just for yourself.
</Accordion>
<Accordion title="A colleague cannot make the view public or delete it">
Only the owner of a personal view decides who it is shared with, and can make it public or delete it. Colleagues you share it with can edit tasks in it.
</Accordion>
<Accordion title="I see the Unsaved changes bar">
You have changed filters or view settings, and they are still only on your screen. Choose **Save view** to keep them or **Discard** to go back. On **All** you need the permission **Manage labels and shared views** for that; without it you can only discard there.
</Accordion>
<Accordion title="A task is not in my list">
A list only shows tasks that you add to it yourself. If you want everything that matches a rule to be added automatically, choose a filtered view under **Type**.
</Accordion>
<Accordion title="The order of the tabs is not saved">
Then Tillor shows **Failed to reorder views**. Drag the tabs again.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Table, board and calendar" href="/taken/indelingen" />
  <Card title="Filtering" href="/taken/filteren" />
  <Card title="Private tasks" href="/taken/prive-taken" />
</Cards>


# Terrains (/en-GB/terreinen)

A terrain is a place in your park: a plot, chalet, motorhome pitch or permanent pitch. Here you create your terrains, give them a type and a tariff and attach meters to them. Then you put customers on them with an [occupation](/bezettingen) or a [reservation](/reserveringen). You find them under <UIPath>Park > Terrains</UIPath>.

<DocScreenshot src="/screenshots/park/terrains-list.png" alt="Terrains overview with demo terrain 12" />

## How does this fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  T[Terrein] --> M[Meters]
  T --> Tar[Berekend tarief]
  K[Klant] -->|bezetting| T
  Tar --> F[Facturen]
  M --> V[Verbruik van de klant]
  V --> F
```

Everything that belongs to that place is attached to a terrain. The tariff follows from the surface area and the custom fields of the terrain. The meters on the terrain provide the consumption, and that consumption goes to the customer with an active occupation. See also [Meter management](/meterbeheer#hoe-hangt-dit-samen).

<Callout type="info" title="Good to know">
- The name is required and may have at most 255 characters.
- **Bookable** is off by default for a new terrain.
- Tillor calculates the surface area as soon as you draw the terrain on the map. You do not type it in yourself.
- **Recent Terrains** counts the terrains from the past 7 days.
- A terrain has at most one active occupation at a time.
- The calculated tariff is recalculated as soon as you save a terrain, and for all terrains as soon as you save the tariff formula.
- If you delete a terrain type, the terrains remain, but they then have no type any more.
</Callout>

## Creating a new terrain [#een-nieuw-terrein-aanmaken]

Before you start: if you need terrain types (such as **Pitch** or **Chalet**) or custom fields, create those first. See [Terrain types](#terreintypes) and [Custom fields](/eigen-velden).

<Steps>
<Step>
### Click Create new terrain [#klik-op-nieuw-terrein-aanmaken]
You find the button at the top right of <UIPath>Park > Terrains</UIPath>.

<DocScreenshot src="/screenshots/park/terrain-create-dialog.png" alt="Create terrain dialog" />
</Step>
<Step>
### Fill in the details [#vul-de-gegevens-in]
Only the **Name** is required. You can also fill in:

- **Description**, an explanation.
- **Terrain type**, or leave **No type**.
- **Custom fields** that your organisation has added itself, such as a surcharge or a gas meter number.
- **Bookable**, if customers may reserve the terrain online.
- **Location**, to point out the terrain on the map straight away.
</Step>
<Step>
### Click Create terrain [#klik-op-terrein-aanmaken]
The terrain is in the list. If you did not draw the location, you do that later on the map, see [Map](/kaart#terreingrenzen-intekenen).
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The terrain appears in the list and in the statistics at the top: **Total Terrains**, **Recent Terrains**, **Bookable Terrains**, **Non-Bookable Terrains** and **Total Surface Area** (only of terrains with a drawn location).
- Tillor calculates the **Calculated tariff** from your organisation's tariff formula.
- On the detail page you can link meters, add comments and see the history.

## Viewing and editing a terrain [#een-terrein-bekijken-en-bewerken]

Click a terrain in the list. At the top are the name, description, surface area, the number of meters, whether it is bookable, the **Customer** with an active occupation and the creation and modification date. In the **Update terrain** form you change:

- **Name**, **Terrain type**, **Description**, **Bookable** and the **Custom fields**.
- **Surface area** and **Calculated tariff** are read-only.

Save with **Update terrain**. Next to the form are **Location**, **Meters** and **Occupation history**. Below that are **Comments** (only visible to your colleagues), **Events** with a before/after overview per changed field, and **Reservations**.

<DocScreenshot src="/screenshots/park/terrain-detail.png" alt="Terrain detail with linked meters" />

## Attaching meters to a terrain [#meters-aan-een-terrein-hangen]

In the **Meters** card you choose **Add meter** and then **Assign meter**. Only meters without a terrain are in the list. For each meter you see the type, a status indicator and the latest reading. With the menu (...) you choose **Unlink from terrain**; that choice is only here. The whole route to the customer is described under [Linking a meter to a customer](/meterbeheer/meter-koppelen).

## Terrain types [#terreintypes]

With terrain types you classify terrains, for example **Pitch**, **Chalet** or **Motorhome pitch**. You see the type in the terrain list (column **Type**, with a filter), you can colour the map by it and it is in the export. You manage them under <UIPath>Support > Settings > Terrain types</UIPath>.

<Requires permission="Edit settings" />

<DocScreenshot src="/screenshots/instellingen/settings-terrain-types.png" alt="Settings > Terrain types" />

The **All terrain types** table shows for each type the **Name**, **Map color**, **Description** and the number of **Terrains**. Search with **Search terrain types...**. With the pencil you edit a type, with the bin you delete it.

<Steps>
<Step>
### Click New terrain type [#klik-op-nieuw-terreintype]
</Step>
<Step>
### Fill in the details [#vul-de-gegevens-in-1]
Give a **Name**, optionally a **Description**, and choose a **Map color**. Blue is preselected.
</Step>
<Step>
### Click Create [#klik-op-aanmaken]
</Step>
</Steps>

<DocScreenshot src="/screenshots/instellingen/terrain-type-create-dialog.png" alt="Create terrain type dialog" />

You link a type to a terrain via the **Terrain type** field. You see the map colour on the map when you set the colours to **Terrain type** under **Layers**, see [Map](/kaart#lagen-en-kleuren).

## Exporting terrains [#terreinen-exporteren]

Click **Export all terrains** (top right) to download an Excel file. For each terrain it contains the basic details, the terrain type, the custom fields and the tariff calculation (subtotal, surcharges and total). Use it, for example, for the annual tariff check.

## How the tariff is determined [#hoe-het-tarief-tot-stand-komt]

The **Calculated tariff** follows from your organisation's tariff formula. The formula works with the surface area and with the custom fields of the terrain. Which custom fields those are, you decide yourself. The default formula uses the fields with the keys `locationSurcharge`, `gasMeterNumber`, `electricityMeterSurcharge` and `staticPrice`. If you have created those under <UIPath>Support > Settings > Custom fields</UIPath>, they work like this:

1. **Surface area**: the drawn surface area, in bands per m².
2. **Gas meter surcharge**: is added if the field with the gas meter number is filled in.
3. **Location surcharge**: the amount you enter.
4. **Electricity surcharge**: the amount you enter.
5. **Static price**: if this field is filled in, that amount replaces the calculated tariff and Tillor skips the formula.

If you want to change a year's tariff, adjust the custom fields, check under **Calculated tariff** whether it is right and save with **Update terrain**.

### Tariff formula [#tariefformule]

<Requires permission="Edit terrain tariff formula" />

Under <UIPath>Settings > Terrain tariff</UIPath> you decide yourself how the tariff is calculated. Whoever was already allowed to edit the settings has been given the **Edit terrain tariff formula** permission. The formula is a piece of TypeScript (a programming language) that returns the annual tariff in euros, or named parts that together make up the tariff, such as `Subtotaal` and `Toeslag gasmeter`. Each part gets its own column in the export.

- You read fields of the terrain with `{terrain.veld}`, such as `{terrain.surfaceArea}` or `{terrain.customFields.locationSurcharge}`. Via the **Variable** button or by typing `{` you choose from all fields, including your own.
- To the right of the formula you try them out straight away on one of your terrains. An error is shown there with the line number. A formula that does not work cannot be saved.
- With **Reset to default** you go back to the formula every organisation started with.
- In automations you read the tariff as `{terrain.calculatedTariff.total}`.

<Callout type="warn" title="Note">
The formula runs in isolation: it can only calculate with the fields of the terrain, without other data or internet. A formula that takes too long to calculate is aborted and then produces no tariff.
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says Terrain not created">
The terrain has not been saved. Check that the **Name** is filled in and is no longer than 255 characters, and try again.
</Accordion>
<Accordion title="The surface area is empty or 0">
The surface area only comes from the location on the map. Draw the terrain via <UIPath>Park > Map</UIPath>, see [Map](/kaart#terreingrenzen-intekenen). Terrains without a location do not count towards **Total Surface Area**.
</Accordion>
<Accordion title="The Calculated tariff is not right">
Check the terrain's custom fields (surcharges and gas meter number). If a **Static price** is filled in, it replaces the calculated tariff. If the formula has been changed, check under Terrain tariff whether the test on this terrain is right.
</Accordion>
<Accordion title="I do not see Terrain tariff in the settings">
You need the **Edit terrain tariff formula** permission. Ask your administrator for it.
</Accordion>
<Accordion title="The meter is not in the list under Add meter">
That meter is already attached to another terrain. Unlink it there first.
</Accordion>
<Accordion title="I cannot create an occupation on this terrain">
A terrain with an active occupation is not in the selection list. End the current occupation first.
</Accordion>
</Accordions>

## Concepts [#begrippen]

- **Terrain**: a place in your park. See [Concepts](/begrippen#terrein).
- **Terrain type**: a classification such as **Pitch** or **Chalet**, with a map colour.
- **Bookable**: customers may reserve the terrain online.
- **Calculated tariff**: the tariff that Tillor calculates from the formula.
- **Custom field**: a field that your organisation adds itself. See [Concepts](/begrippen#eigen-veld).
- **Occupation**: a customer on a terrain for a period. See [Concepts](/begrippen#bezetting).

## See also [#zie-ook]

<Cards>
  <Card title="Meter management" href="/meterbeheer" description="Link meters to terrains and invoice consumption" />
  <Card title="Occupations" href="/bezettingen" description="Put customers on a terrain" />
  <Card title="Map" href="/kaart" description="Draw terrain boundaries" />
</Cards>


# Access control (/en-GB/toegangscontrole)

With Access control you decide who may enter your park and keep track of who is inside. You give a customer an access method (licence plate, NFC tag, QR code or PIN code), operate barriers from your screen and read back who came through which access point and when. You create an access method on the customer profile, see [adding an access method](#een-toegangsmethode-toevoegen).

<DocScreenshot src="/screenshots/toegangscontrole/stats-overview.png" alt="Access control with statistics at the top" />

The figures at the top count all entries, the last 24 hours, the allowed and blocked attempts and your active access points. Below that are the quick actions, the vehicles in the park, the access log and the controller operations.

<Callout type="info" title="Good to know">
- A vehicle becomes a **Ghost** if it has not been seen at an access point for 7 days while it was marked **Inside**.
- You create a QR access method in one go, up to 100 at a time, each with its own code.
- A PIN code consists of 4 to 8 digits and must be unique within your organisation.
- Each licence plate, each NFC tag and each QR code may only appear once in your organisation.
- An access method that falls outside the period between **From date** and **To date** gives no access.
- A licence plate with the status **Soft blocked** is only blocked during reception opening hours.
- An expired licence plate may by default still drive out for 2 days outside opening hours (at most 30). See [Access control settings](/gebruikers/instellingen-toegangscontrole).
- A vehicle appears on the customer profile via a registered licence plate, or via the NFC tag or QR code the customer drove in with.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

An access method is a customer's key. The access point (the barrier or gate) is the door. In between is equipment in your park: a camera that reads licence plates or a unit that reads tags and QR codes (an access controller), and the [connector](/connector). The connector is the unit that connects Tillor to the devices in your park.

```mermaid
flowchart TD
  K[Customer] --> M[Access method<br/>licence plate, NFC tag, QR code or PIN code]
  M -->|Tillor sends the list| C[Connector in your park]
  C --> L[Camera or card reader<br/>at the entrance]
  L -->|allowed| P[Access point opens]
  L -->|refused| W[Access point stays closed]
  L -->|every attempt is reported| LOG[Access log in Tillor]
```

What this means for you:

- If you change or delete an access method in Tillor, Tillor sends that to the equipment via the connector. You see the result under **Controller Operations**.
- If the connector is offline, new or changed access methods stay on **Pending** until it is connected again.
- A barrier that you open from Tillor usually also receives its command via the connector. If it is offline, the barrier does not open.

The Controllers section in the main menu is about something else: the small screens with a tag reader at showers, doors and charge points. See [Controllers](/controllers). Tillor support sets up the equipment at barriers during onboarding.

## Operating access points [#toegangspunten-bedienen]

Under **Quick actions** there is a button for every active access point. You only see this block if at least one access point or access controller has been set up.

<DocScreenshot src="/screenshots/toegangscontrole/quick-actions.png" alt="Quick actions with access points and management buttons" />

<Steps>
<Step>
### Click the access point's button [#klik-op-de-knop-van-het-toegangspunt]
The label is **Open [name]**.
</Step>
<Step>
### Confirm [#bevestig]
A dialogue opens asking whether you are sure you want to open the access point. Click **Yes, open [name]**.

<DocScreenshot src="/screenshots/toegangscontrole/barrier-confirm-dialog.png" alt="Confirmation to open an access point" />
</Step>
</Steps>

Tillor reports **Access point opened**. Closing is only possible if the access point supports it. In that case there is a down arrow next to the open button: choose **Close [name]** there and confirm with **Yes, close [name]**.

### Management buttons in Quick actions [#beheerknoppen-in-snelle-acties]

Next to the access points there are, depending on your equipment, buttons for maintenance. Only use them if something is wrong.

| Button | What it does | When |
|---|---|---|
| **Reset APB** | Clears the memory of who last went in or out, per type: **For NFC passes…** or **For QR codes…**. | People can no longer get through because the gate thinks they are already inside (or outside). APB stands for anti-passback. |
| **Sync device logs** | Has the connector fetch all new lines from the access controllers. | Recent passages are missing from the access log. |
| **Reset connector cache** | The connector clears its local data and fetches everything again from Tillor. | The equipment behaves differently from the access methods in Tillor. |
| **Clean trash LPR readings** | Only removes safe ghost rows from the licence plate list. Registered and linked licence plates stay. | There are licence plates in the list that do not belong to anything. |

## Managing access methods via the customer profile [#toegangsmethoden-beheren-via-het-klantprofiel]

You add, change and delete access methods on the customer's profile.

### Adding an access method [#een-toegangsmethode-toevoegen]

An access method belongs to a customer and gives that customer access to the park. You manage them on the customer profile.

Before you start:

- The customer exists in Tillor.
- For NFC you need a tag that does not yet belong to anyone. If there is no free tag, the list says **No available NFC cards found, all cards are already assigned.**
- The **PIN code** type is only in the list if it has been enabled for your organisation.

<Steps>
<Step>
### Open the Access control tab [#open-het-tabblad-toegangscontrole]
Go to <UIPath>Customers > customer > Access control</UIPath>. At the top is the **Access Methods** table (marker **1** on the screenshot below).

<DocScreenshot src="/screenshots/klanten/customer-access-control.png" alt="Customer profile Access control with Access Methods table and licence plate 1-DOC-2026" />
</Step>
<Step>
### Click Add and choose the type [#klik-op-toevoegen-en-kies-het-type]
<DocScreenshot src="/screenshots/toegangscontrole/access-method-create-dialog.png" alt="Dialogue for a new access method" />

You cannot change the type afterwards. If you need a different type, add a new access method.
</Step>
<Step>
### Fill in the details [#vul-de-gegevens-in]
What you fill in depends on the type:
</Step>
</Steps>

<Tabs items={["Licence plate", "NFC", "QR code", "PIN code"]}>
<Tab value="Licence plate">
Enter the licence plate under **License plate**. Tillor converts it to capitals. Make, model and colour are optional.
</Tab>
<Tab value="NFC">
Under **NFC Cards** choose a free tag from the list. You can search by the tag's number.
</Tab>
<Tab value="QR code">
Tillor creates the code itself. With **Quantity** you create up to 100 separate QR access methods in one go, each with its own code. Tick **Print thermal ticket immediately** to send every new QR straight to the thermal printer as an entry ticket. You set the printer address in the organisation settings. The ticket shows **Valid from** and **Valid until** in your organisation's time zone.
</Tab>
<Tab value="PIN code">
Enter 4 to 8 digits, or click **Generate**. The PIN code must be unique within your organisation. For a PIN code the **Sync with access point system** action is not available.
</Tab>
</Tabs>

For every type you can also fill in:

| Field | Meaning |
|---|---|
| **From date**, **To date** | The period in which the access method works. Empty means no limit. |
| **Status** | **Active**, **Inactive**, **Blocked** or **Soft blocked** (see [statuses](#statussen-van-toegangsmethoden)). |
| **Auto-convert to license plate** | Only for QR code and PIN code. If someone uses the code at a gate with a camera, Tillor replaces the code with the licence plate that was read. Off by default. |
| **Do not extend automatically** | The end date stays unchanged when an invoice with automatic extension is paid. |
| **Notes** | Internal notes. |

Then click **Add** to save.

#### What happens next? [#wat-gebeurt-er-daarna]

- The access method appears in the table and Tillor sends it to the equipment via the connector. You follow that under **Controller Operations**, with the status <Status tone="info">Pending</Status>, <Status tone="warning">Processing</Status>, <Status tone="success">Completed</Status> or <Status tone="error">Failed</Status>.
- A changed or deleted access method is passed on in the same way.
- Every attempt to get in appears in the access log, including refused ones.
- A vehicle is linked to the customer via a registered licence plate, or because the customer drove in with an NFC tag or QR code while the camera also read the licence plate. That last case also works if the licence plate is not registered.

#### Editing, sending or deleting an access method [#een-toegangsmethode-bewerken-versturen-of-verwijderen]

Click the three dots to the right of the access method.

<DocScreenshot src="/screenshots/toegangscontrole/access-method-actions-menu.png" alt="Actions menu of an access method" />

| Action | Used for |
|---|---|
| **Edit** | Adjusting the period, status or vehicle details. |
| **Sync with access point system** | Sending it to the equipment again. Tillor reports **Sync requested**. Not for a PIN code. |
| **Send notification** | Sends the customer the personal QR link by email, SMS or WhatsApp (dialogue **Send QR code**). |
| **Copy personal URL** | Copies the link to the customer's pass, see [Digital wallet](#digitale-wallet-qr-code). |
| **Download QR code**, **Print thermal ticket** | Only for a QR code. |
| **Delete** | Removes the access method. This cannot be undone. With the ticks in the table you delete several at once. |

#### Statuses of access methods [#statussen-van-toegangsmethoden]

| Status | Meaning |
|---|---|
| <Status tone="success">Active</Status> | Gives access, as long as the period is correct. |
| <Status>Inactive</Status> | Gives no access. Works like Blocked, with a clearer name. |
| <Status tone="error">Blocked</Status> | Gives no access. |
| <Status tone="warning">Soft blocked</Status> | For a licence plate, only blocked during reception opening hours. Outside those hours the vehicle can still drive in and out. |

## Digital wallet (QR code) [#digitale-wallet-qr-code]

For a QR access method you copy a personal link for the guest. It opens the **Access pass** page with the QR code. If Apple Wallet or Google Wallet have been set up for your environment, there are also buttons to save the pass.

<Steps>
<Step>
### Copy the link [#kopieer-de-link]
Open the three dots at the QR access method and click **Copy personal URL**. Tillor reports **Link copied**.

<DocScreenshot src="/screenshots/toegangscontrole/access-method-personal-url-menu.png" alt="Actions menu of a QR access method with Copy personal URL" />
</Step>
<Step>
### Send the link to the guest [#stuur-de-link-naar-de-gast]
The guest sees the QR code, the validity and, if available, **Add to Apple Wallet** and **Add to Google Wallet**.

<DocScreenshot src="/screenshots/toegangscontrole/access-method-public-view-wallet.png" alt="Guest page Access pass with QR code and wallet buttons" />
</Step>
</Steps>

The wallet pass uses the same QR code, validity and status as in Tillor. On an iPhone with iOS 27 the pass appears as a Poster Generic, optionally with its own background and a square QR code. Older iPhones show the classic layout. On iOS 27 there are also shortcuts on the pass: **Directions** opens Apple Maps to the location of the access point (or the centre of the park map), and if you have entered a website in your company details, a button to that site is added. You set the background and location under **Settings**, see [Organisation](/gebruikers/organisaties). On an iPhone the pass can appear on the lock screen when the guest is nearby. On Android the guest saves the pass in Google Wallet.

### Seeing where the pass is saved [#zien-waar-de-pas-is-opgeslagen]

If a guest has added the pass, a small wallet icon appears next to the QR value, with a number if there is more than one device. Hover over it to see:

- whether the pass is in **Apple Wallet on iPhone** or **Google Wallet on Android**, and on how many devices
- when the pass was **Last added** and **Pass updated**, and for Apple also **Last synced**
- whether the pass was **Issued via** a **Staff** member or a **Personal link**

Google does not report when a guest removes the pass. With Google Wallet the pass therefore stays shown as saved.

### Sending a wallet pass again [#een-wallet-pas-opnieuw-versturen]

If a QR pass changes, for example its validity, Tillor sends the update to the wallets itself. If an old version is still shown, choose **Sync wallet pass** in the menu. Tillor reports how many devices received the update. If the pass is not registered anywhere yet, you see **No device registered for updates yet.** The menu item only appears once the pass has been added to a wallet.

## Vehicles in the park [#voertuigen-in-het-park]

The **Vehicles in park** table keeps track per licence plate of whether a vehicle is inside. A reading at an entrance sets the vehicle to **Inside**, a reading at an exit to **Left**.

Each row shows the licence plate, the status, the customer, the time of entry, the last time the vehicle was seen at an access point and that access point. By default the table shows the vehicles that are **Inside** or **Ghost**. With the filters you also show vehicles that have left, filter by access point or search by licence plate or customer name.

| Status | Meaning |
|---|---|
| <Status tone="success">Inside</Status> | Came in through an entrance and has not left yet. |
| <Status tone="warning">Ghost</Status> | Was set to Inside, but has not been seen at an access point for 7 days. |
| <Status>Left</Status> | Drove out through an exit. |

A ghost vehicle usually arises because the camera did not read the licence plate when driving out, or read it wrongly when driving in. If the licence plate is seen again at an entrance later, it is set to **Inside** again.

### Park occupancy [#parkbezetting]

The **Park occupancy** card shows how many vehicles are inside: **Currently inside**, the **Peak** in the chosen period, and the number of **Entries** and **Exits**. The first chart shows the trend, per hour up to a week and per day for a longer period. **Popular hours** shows per hour of the day the average number of vehicles and arrivals. This way you can see, for example, when it is busy enough to open the catering. With the period picker at the top right you choose today, 7 days, 30 days, 90 days, all or a custom range.

## Access log [#toegangslogboek]

The access log shows every attempt to get in, with date, access method, customer (if known), access point and status.

<DocScreenshot src="/screenshots/toegangscontrole/access-log.png" alt="Access log with licence plates, customer and status" />

Filter and search by licence plate or value (for NFC also by card label), date range, status, type of access method, access point or customer. With **Export** on the right of the toolbar you download the log as an Excel file.

| Status | Meaning |
|---|---|
| Allowed | Access was granted. |
| Blocked | Access was refused. |
| Inactive | The access method is set to inactive. |
| Expired | The access method has expired. |
| Invalid | The access method is invalid. |
| Denied | Access was actively denied. |
| Soft blocked | Access is soft blocked. |
| Device Error | There was a problem with the device. |
| No Car | No car was detected. |
| APB - Direction Mismatch | The gate blocks passage because the direction is wrong (anti-passback). |
| Unknown | The status could not be determined. |
| System Message | A message from the system itself. |

## Access point state history [#hekstatusgeschiedenis]

Below the access log there is also the **Access point state history**: when an access point was **Open**, **Closed** or **Moving**, with the **Source** of the report. If the state is not known, it says **Unknown**. Filter by status or access point. If the list is empty, no state reports have been received yet.

## Controller Operations [#controller-operaties]

Below that is **Controller Operations**. These are the commands Tillor sends to the access controllers, such as **Create**, **Update**, **Delete** and **Sync**. This way you see when a pass or QR code has arrived at the access point.

<DocScreenshot src="/screenshots/toegangscontrole/controller-operations.png" alt="Controller Operations with commands and their status" />

A command is <Status tone="info">Pending</Status>, <Status tone="warning">Processing</Status>, <Status tone="success">Completed</Status> or <Status tone="error">Failed</Status>. With the eye icon on the right of the row you open the details.

## Problems? [#problemen]

<Accordions>
<Accordion title="The Quick actions block is missing">
The block only appears if an access point or access controller has been set up. If there is nothing, Tillor support has not yet connected the equipment.
</Accordion>
<Accordion title="Tillor says: Failed to open access point">
The access point did not respond. Usually the connector is offline or the device cannot be reached. Check the connector, see [Connector not connected](/connector#problemen), and try again.
</Accordion>
<Accordion title="Tillor says: This credential value is already in use">
Each licence plate, each NFC tag and each QR code may only appear once in your organisation. For a licence plate, Tillor says which customer it is already on. First delete or change that access method.
</Accordion>
<Accordion title="A customer cannot get in with a valid licence plate">
Check in the access log which status the attempt received. **Expired** or **Inactive**: check **From date**, **To date** and **Status** of the access method. **Soft blocked**: the licence plate is blocked during reception opening hours. **Device Error** or **No Car**: the camera read nothing, check the equipment. If the access method is correct but the gate still refuses, check under **Controller Operations** whether the last change is **Completed**.
</Accordion>
<Accordion title="A new access method does not work at the gate yet">
Check under **Controller Operations** whether the command is <Status tone="success">Completed</Status>. If it is **Pending**, the connector is probably offline. If it is **Failed**, choose **Sync with access point system** at the access method.
</Accordion>
<Accordion title="People are refused with APB - Direction Mismatch">
The gate thinks they are already inside (or outside). Click **Reset APB** in Quick actions and choose **For NFC passes…** or **For QR codes…**. Confirm with **Reset**.
</Accordion>
<Accordion title="The list of NFC tags is empty">
Only tags that do not yet belong to anyone are in the list. First remove a tag from the other customer, see [Managing tags](/nfc/nfc-tags#wat-kun-je-met-een-tag-doen).
</Accordion>
<Accordion title="A vehicle is shown as Ghost">
The vehicle has not been seen for 7 days. Usually it has gone without the camera seeing it. It becomes **Inside** again automatically if the licence plate is read at an entrance again.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Access method**: a customer's key, a licence plate, NFC tag, QR code or PIN code.
- **Access point**: the barrier, gate or door that opens.
- **Access controller**: the unit at the access point that reads tags and QR codes.
- **Connector**: the unit in your park that connects Tillor to the equipment. See [Connector](/connector).
- **APB (anti-passback)**: the rule that you cannot go through a gate twice in the same direction.
- **Ghost vehicle**: a vehicle that is marked as inside but has not been seen for 7 days.

More explanation is in the [list of terms](/begrippen).

## See also [#zie-ook]

<Cards>
  <Card title="Connector" href="/connector" description="The unit that connects Tillor to your equipment" />
  <Card title="NFC" href="/nfc" description="Linking tags and managing balance" />
  <Card title="Access control settings" href="/gebruikers/instellingen-toegangscontrole" description="Grace period for expired licence plates" />
  <Card title="Customer management" href="/klantenbeheer" />
</Cards>


# Weather (/en-GB/weer)

On the **Weather** page you see the weather at your park's location for each day, so you can compare a peak in consumption or busyness with the weather. Tillor also uses this data for meters and reservations.

<Callout type="info" title="Good to know">
- The weather belongs to your organisation's map centre. If that is wrong, the weather will be wrong too.
- Tillor fetches the weather every night and fills in missing days from the past.
- By default you see the last 14 days.
- A day marked **Archived** is final. A day marked **Forecast** can still change.
</Callout>

## Opening the page [#de-pagina-openen]

Go to <UIPath>Park > Weather</UIPath>.

<DocScreenshot src="/screenshots/weer/weather-overview.png" alt="Park > Weather with the daily forecast" />

Under **Daily forecast** you see the location, for example **Map centre: 50.8503, 4.3517**. This is your park's map centre. You set it under <UIPath>Settings > Map</UIPath>. If you move it, the weather follows the new location. See [Map](/kaart).

You see:

- a large card for the most recent day with the temperature, condition, highest and lowest temperature and the amount of rain. Next to the day it says **Archived** for a day that is already final, or **Forecast** for a day that can still be updated
- below that, a card for each day, with the condition such as **Clear**, **Partly cloudy**, **Overcast**, **Fog**, **Drizzle**, **Rain**, **Showers**, **Snow** or **Thunderstorm**, the highest and lowest temperature, and the rain in mm. Today has a coloured border
- **No data for this day** on a day for which Tillor has nothing

## Choosing a different period [#een-andere-periode-kiezen]

By default you see the last 14 days. Click **Select a period** at the top right to choose a different period: **Today**, **Yesterday**, **Last 7 days**, **Last month**, **Last 3 months**, **All** or a **Custom range** on the calendar. Confirm your own range with **Apply**.

## No weather data yet [#nog-geen-weergegevens]

If it says **No weather data yet**, the weather has not been fetched yet. Tillor fetches it every night for your organisation's map centre and also fills in missing days from the past. Try a different period or come back the next day. Also check that the map centre is correct.

## Where else you see the weather [#waar-zie-je-het-weer-nog-meer]

- On the meter page, under **Consumption & trends**: on a peak day the temperature is shown, and with increased consumption a summary of the last 7 days. See [Meter management](/meterbeheer/meterstanden-en-trends#verbruik-en-trends-lezen).
- On the reservations timeline and in the charts of vehicles at the park, with the weather of that day.

## Problems? [#problemen]

<Accordions>
<Accordion title="It says No weather data yet">
The weather has not been fetched yet. Try a different period or come back the next day, and check that the map centre is correct.
</Accordion>
<Accordion title="The weather does not match my park">
The map centre is in a different place. Move it under <UIPath>Settings > Map</UIPath>, see [Map](/kaart#kaartstandaard-instellen). The weather follows the new location.
</Accordion>
<Accordion title="A day says No data for this day">
Tillor has nothing for that day. It is filled in automatically when the data becomes available.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Map" href="/kaart" description="Set your park's map centre" />
  <Card title="Meter management" href="/meterbeheer" description="Consumption and trends per meter" />
</Cards>


# Overview (/en-GB/api-referentie)

This reference is generated directly from the Tillor API. Each endpoint has its own page with parameters, request body, possible responses and code examples. In the sidebar the endpoints are grouped by topic.

## Sending a request [#een-request-versturen]

Every request needs your API key in the `x-api-key` header. Endpoints under `/orgs/{organizationId}` work within one organisation.

```http
GET https://api.tillor.eu/orgs/org_abc123/customers
x-api-key: tkn_xxx
```

You create an API key in the app, under your account. How that works, which rate limits apply and how to keep keys safe is explained in [HTTP API](/ontwikkelaars/http).

## Who may call an endpoint [#wie-mag-een-endpoint-aanroepen]

Every endpoint page shows at the top, under **Access**, who may call the endpoint. For most endpoints that is a member of the organization with a given permission, such as `customers:read`. An API key works with the permissions of the person who created it; if the key has scopes, the permission must be among them too. Otherwise the API answers `403`.

The specification carries the same information per endpoint in `x-tillor-access`, with `access` (who) and `permissions` (one of them is enough).

## Trying it out in the playground [#uitproberen-in-de-playground]

On every endpoint page you can send the request straight away. If you are signed in to Tillor in the same browser, the playground uses your session and you do not need an API key. Otherwise, enter your API key under **Authorization**. Adjust the parameters and click **Send**.

The playground talks to the real API of your organisation: a `POST`, `PUT` or `DELETE` therefore changes real data.

<Callout type="warn" title="Use a test organisation">
Try out endpoints that write data on a test organisation, not on your live park.
</Callout>

## Downloading the specification [#specificatie-downloaden]

The full specification is available as OpenAPI 3.1 at [tillor.eu/api/openapi.json](https://tillor.eu/api/openapi.json). Import it into Postman or Insomnia, or generate a client from it.

## See also [#zie-ook]

<Cards>
  <Card title="HTTP API" description="Authentication, rate limits and conventions" href="/ontwikkelaars/http" />
  <Card title="Webhooks" description="Receive events at your own URL" href="/ontwikkelaars/webhooks" />
</Cards>


# Managing a controller (/en-GB/controllers/controller-beheren)

On a controller's page you change its details and carry out maintenance. Settings such as ACL, network and updates are covered separately in [Controller settings](/controllers/settings).

Before you start:

- The controller is approved, see [Connecting a controller](/controllers/controller-koppelen).

## Changing the name, type and group [#naam-type-en-groep-wijzigen]

<Steps>
<Step>
### Open the controller [#open-de-controller]
Go to <UIPath>Controllers > Overview</UIPath> and click the controller.
</Step>
<Step>
### Adjust the form [#pas-het-formulier-aan]
Under **Controller settings** you choose the **Name**, the **Type** (**Shower**, **Access** or **Charge point**) and the **Group**.
</Step>
<Step>
### Click Save [#klik-op-opslaan]
Tillor reports **Controller updated** and sends the settings to the controller.
</Step>
</Steps>

## Restarting a controller [#een-controller-herstarten]

If a controller is not responding properly, restart it from Tillor.

<Tabs items={["On the detail page", "In the overview"]}>
<Tab value="On the detail page">
Open the actions menu (the three dots) and choose **Reboot controller**.

<DocScreenshot src="/screenshots/controllers/controller-actions-menu.png" alt="Actions menu of a controller with Reboot controller" />
</Tab>
<Tab value="In the overview">
Click the restart icon in the controller's row.
</Tab>
</Tabs>

The screen shows **Restarting** and the controller then reconnects.

The actions menu also has **View logs in Grafana**. This opens the controller's logs in another program, intended for support. On the controller page itself, the recent logs are in the **Console** card.

## Updating to a new version [#bijwerken-naar-een-nieuwe-versie]

If there is an arrow pointing up next to the version number, a newer <Term term="firmware">firmware</Term> (software) is available. Hover over it to see the version (**Update available**) and click it to start the update. Tillor reports **OTA update started**. When controllers update themselves, you can read about it in [Firmware updates](/controllers/updates).

## Deleting a controller [#een-controller-verwijderen]

In the actions menu choose **Delete controller** and confirm under **Delete controller**. The controller disappears from your list. Afterwards it can request adoption again.

## What happens next? [#wat-gebeurt-er-daarna]

- After a restart the controller reconnects to Tillor. This takes a moment.
- After updating, the controller restarts by itself. Leave the power on while the screen shows **Update** with a percentage.
- A deleted controller no longer grants access.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says: Reboot failed">
The controller could not be restarted, usually because it is offline. Check the power and network, see [Connection problems](/controllers/troubleshooting/verbinding).
</Accordion>
<Accordion title="Tillor says: OTA update failed">
The update could not be started. Check that the controller is online and that **Skip OTA updates** is set to **No**, see [Firmware updates](/controllers/updates).
</Accordion>
<Accordion title="Tillor says: Update failed">
The form could not be saved. Try again and check that the name is filled in.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Controller settings" href="/controllers/settings" description="ACL, network, updates and relays" />
  <Card title="Firmware updates" href="/controllers/updates" description="Update window and frequency" />
</Cards>


# Connecting a controller (/en-GB/controllers/controller-koppelen)

A new controller only works for your organisation once you have approved it. This is called adoption: you tell Tillor that this unit belongs to your park. After that you can give it a type and a group, see [Managing a controller](/controllers/controller-beheren).

Before you start:

- You have power and a network (cable or Wi-Fi) at the spot where the controller will go.
- If you use Wi-Fi, you have the network name and password to hand.
- Preferably open Tillor on the same network as the controller. Otherwise you may not see its request.

## Connecting and approving the controller [#de-controller-aansluiten-en-goedkeuren]

<Steps>
<Step>
### Connect the controller [#sluit-de-controller-aan]
Plug in the power. The screen shows **Connecting...** and then what is still missing.
</Step>
<Step>
### Give it a network [#geef-hem-een-netwerk]
<Tabs items={["Network cable", "Wi-Fi"]}>
<Tab value="Network cable">
Plug in the network cable. The controller connects by itself, you do not need to set anything up.
</Tab>
<Tab value="Wi-Fi">
On the screen, tap **Set up Wi-Fi**, choose your network, type the password and confirm. The screen shows **Connected**. See [Setting up Wi-Fi on the screen](/controllers/troubleshooting/verbinding#wifi-instellen-op-het-scherm).
</Tab>
</Tabs>
</Step>
<Step>
### Open Controllers in Tillor [#open-controllers-in-tillor]
Go to <UIPath>Controllers > Overview</UIPath>. As soon as the controller has a connection, it appears in the list with the message **Pending approval**. The controller's screen shows **Activate controller** with the device number. That number is the <Term term="eFuse ID">eFuse ID</Term>, the unit's serial number. Check that it is the same as in the list.
</Step>
<Step>
### Click Approve [#klik-op-goedkeuren]
Click the tick (**Approve**) in the row. Tillor reports **Approved** and the controller is added to your organisation.
</Step>
</Steps>

## What happens next? [#wat-gebeurt-er-daarna]

- The controller's screen shows **Scan QR** and **Scan your tag**. It is ready for use.
- Tillor automatically sends the connection details and settings to the controller. You do not need to fill in anything.
- Its first scan creates the tag in Tillor, if it was not there yet.
- With the cross (**Reject**) you reject a request. The controller then gets no access to your organisation.
- If you put a controller away later or replace it, delete it, see [Managing a controller](/controllers/controller-beheren#een-controller-verwijderen). It can then make a new request.

## Problems? [#problemen]

<Accordions>
<Accordion title="The controller is not in the list">
The screen must show **Activate controller** before it appears. If it still says **Set up Wi-Fi** or **Connecting...**, it is not online yet. Also try opening Tillor from the same network as the controller and refresh the page. More steps are in [Controller does not appear in Tillor](/controllers/troubleshooting/verbinding#controller-verschijnt-niet-in-tillor).
</Accordion>
<Accordion title="Tillor says: Approval failed">
The adoption could not be approved. Try again. If it keeps failing, check that the controller's clock is correct and contact support. See [Adoption failed](/controllers/troubleshooting/verbinding#adoptie-mislukt-of-credentials-worden-geweigerd).
</Accordion>
<Accordion title="The screen stays on Connecting...">
Wait 1 to 2 minutes. If it stays that way, check the cable or the Wi-Fi signal. See [Screen stays on Connecting...](/controllers/troubleshooting/verbinding#scherm-blijft-op-verbinden).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Managing a controller" href="/controllers/controller-beheren" description="Name, group, restarting and deleting" />
  <Card title="Screen messages" href="/controllers/troubleshooting/scherm" description="What the controller shows" />
</Cards>


# Overview (/en-GB/controllers)

A controller is a small unit with a round touchscreen at your park, at a shower, door or charge point. A guest holds an <Term term="NFC">NFC</Term> tag against it, or scans the QR code on the screen, and Tillor decides whether it is allowed. Here you read what a controller does and how it relates to customers and balance. You put a new controller into use via [Connecting a controller](/controllers/controller-koppelen).

The controllers are in the main menu under **Controllers**. The barriers and access controllers at your gate are not part of this, see [Access control](/toegangscontrole).

<Callout type="info" title="Good to know">
- A controller reports to Tillor every 15 seconds. After about 35 seconds without contact, Tillor shows it as offline.
- After 5 minutes without contact, the Tillor team receives an alert.
- A controller remembers a maximum of 8 Wi-Fi networks.
- Access control via the controller (ACL) is off by default. Turn on **ACL enabled** in the [settings](/controllers/settings) to have tags checked.
- By default it checks daily for a new software version. An update only starts within the update window if you have set one.
- By default it waits 1000 milliseconds (1 second) for Tillor before it switches over, under the **API ACL timeout** setting.
- During a short interruption, paying with a tag still works. Paying via the QR code does not work for a moment.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

The controller does not decide by itself who may go through. It reads the tag and asks Tillor. Tillor knows which customer the tag belongs to, which access groups it applies to and how much balance is on it.

```mermaid
flowchart TD
  G[Guest holds tag against the screen] --> C[Controller]
  C -->|asks if it is allowed| T[Tillor]
  T --> K[Customer of the tag]
  T --> A[Access groups and balance]
  T -->|allow or refuse| C
  C -->|shows the result| G
  T --> TR[Transaction in the tag history]
```

- Every controller has a **Type** (**Shower**, **Access** or **Charge point**) and optionally a **Group**. Which tags may be used here is arranged with the tag's access groups, see [Managing tags](/nfc/nfc-tags).
- If the controller cannot reach Tillor for a moment, then with **Local First** it uses the data it has remembered itself, see [Settings](/controllers/settings).
- A tag that is not yet in Tillor is created as soon as it is held against a controller for the first time.

## What do you see in Tillor? [#wat-zie-je-in-tillor]

- **Controllers overview**: all controllers with their version, type, group, usage and when they were **Last seen**. Controllers that want to be connected show **Pending approval**.
- **Controller detail**: status, network, how heavily the controller is loaded, the Wi-Fi networks, the events and the **Console** card with the logs.
- **Management**: restarting, updating and deleting, see [Managing a controller](/controllers/controller-beheren).

## Sections [#onderdelen]

<Cards>
  <Card title="Connecting a controller" href="/controllers/controller-koppelen" description="Connecting and approving" />
  <Card title="Managing a controller" href="/controllers/controller-beheren" description="Name, group, restarting and deleting" />
  <Card title="Setting up Wi-Fi networks" href="/controllers/wifi-netwerken" description="Up to 8 networks in order of priority" />
  <Card title="Controller settings" href="/controllers/settings" description="ACL, network, updates and relays" />
  <Card title="Firmware updates" href="/controllers/updates" description="Update window and frequency" />
  <Card title="Screen messages" href="/controllers/troubleshooting/scherm" description="What does the message on the screen mean?" />
  <Card title="Connection problems" href="/controllers/troubleshooting/verbinding" description="Wi-Fi, Tillor connection and adoption" />
  <Card title="Glossary" href="/controllers/lexicon" description="Terms such as OTA, adoption and ACL" />
</Cards>

## Terms [#begrippen]

- **Controller**: the unit with a screen and tag reader.
- **Tag**: a guest's card, wristband or key fob. See [NFC](/nfc).
- **Adoption**: you connect a new controller to your organisation.
- **ACL**: the list that decides whether a tag is allowed. See [the glossary](/controllers/lexicon).
- **Firmware**: the software in the unit.

More explanation is in the [list of terms](/begrippen).


# Glossary (/en-GB/controllers/lexicon)

An overview of terms you come across when working with controllers. Each term has an explanation and, in a blockquote, what we mean by it in plain language.

## A [#a]

<LexiconList>
<LexiconEntry
  term="ACL"
  termAlt="(Access Control List)"
  definition="Access control via the controller. With ACL on, it checks whether an NFC card is allowed; with ACL off, cards are scanned but not validated. The ACL priority determines whether it first looks locally or consults Tillor online."
  simple="The controller looks in a list to see whether your card is allowed. That list is called the ACL."
/>
<LexiconEntry
  term="Adoption"
  definition="Connecting a controller to your organisation in Tillor. After adoption the controller receives the right settings and can connect to Tillor."
  simple="You tell Tillor 'this controller is ours'. After that the controller knows your organisation and cooperates."
/>
<LexiconEntry
  term="API"
  definition="Consulting Tillor online for access control. With API First the controller always asks Tillor; with Local First it only does so if the card is not found locally."
  simple="The controller asks Tillor online whether a card is allowed. We call that asking online the API."
/>
</LexiconList>

## C [#c]

<LexiconList>
<LexiconEntry
  term="Controller"
  definition="The physical unit at your park. The controller reads NFC cards, checks access and communicates with Tillor."
  simple="The unit at the shower or the door that you hold your tag against."
/>
<LexiconEntry
  term="Credentials"
  definition="Login or connection details. After adoption the controller automatically receives the right credentials to connect to Tillor."
  simple="The login details the controller uses to connect securely to Tillor after adoption. It gets them automatically - you do not need to fill in anything."
/>
</LexiconList>

## E [#e]

<LexiconList>
<LexiconEntry
  term="eFuse ID"
  termAlt="(Electronic Fuse ID)"
  definition="A unique identification number stored in the controller's hardware. Every controller has a different eFuse ID - this is how Tillor recognises which unit it is."
  simple="The unit's fingerprint number. Like a serial number, but built into the chip."
/>
</LexiconList>

## F [#f]

<LexiconList>
<LexiconEntry
  term="Firmware"
  definition="The software that runs on the controller. Through firmware updates the controller gets new features and improvements."
  simple="The program in the unit. Just like your phone getting an update."
/>
</LexiconList>

## N [#n]

<LexiconList>
<LexiconEntry
  term="NFC"
  definition="Near Field Communication - the technology the controller uses to read cards, wristbands and key fobs. You hold the tag against the screen to scan."
  simple="The way the controller reads your tag. You hold the tag against it - no barcode or PIN."
/>
</LexiconList>

## O [#o]

<LexiconList>
<LexiconEntry
  term="OTA"
  termAlt="(Over-The-Air)"
  definition="Updates via the internet, without having to connect anything. The controller downloads and installs new firmware automatically."
  simple="The unit fetches new software by itself via the internet. You do not need to do anything - it happens automatically."
/>
</LexiconList>

## R [#r]

<LexiconList>
<LexiconEntry
  term="Relay"
  definition="A switch in the controller with which you can control an access point or other device."
  simple="A button in the unit that can open or close your access point."
/>
</LexiconList>

## S [#s]

<LexiconList>
<LexiconEntry
  term="Screen"
  definition="The controller's round touchscreen. It shows the status in plain language (ready, paid, refused, no connection), the QR code for paying online, and you set up Wi-Fi on it. The tag reader sits behind the screen."
  simple="The small round screen you hold your tag against. It says what is happening."
/>
</LexiconList>

## T [#t]

<LexiconList>
<LexiconEntry
  term="Tag"
  definition="The NFC carrier a guest receives: a card, wristband, key fob or sticker. In Tillor the tag is linked to a customer and can have a balance."
  simple="The card, wristband or key fob you use to take a shower or get in."
/>
<LexiconEntry
  term="Tillor"
  definition="The park management platform. The controller connects to Tillor to check access and exchange data."
  simple="The program you work in - on your computer or tablet. The controller talks to it."
/>
</LexiconList>

## U [#u]

<LexiconList>
<LexiconEntry
  term="Update window"
  definition="The time window in which the controller may update (e.g. between 02:00 and 04:00). Outside this window no updates are carried out."
  simple="You choose when the unit may update. For example only at night, so nobody is bothered during the day."
/>
</LexiconList>


# Controller settings (/en-GB/controllers/settings)

This is a reference page for a controller's settings. You find them at <UIPath>Controllers > Overview > [controller name]</UIPath>, in the form below the header. Click **Save** to apply changes. Tillor then sends the settings to the controller. You change the name, type and group under [Managing a controller](/controllers/controller-beheren).

## ACL configuration [#acl-configuratie]

The <Term term="ACL">ACL</Term> (Access Control List) determines how the controller checks access. *In other words: how the unit checks whether a card is allowed.*

| Setting | Meaning |
| ---------- | --------- |
| **ACL enabled** | Set to **Yes** to use access control via the controller. With **No**, cards are scanned but not validated. By default this is **No**. |
| **ACL priority** | **Local First**: the controller first checks its own memory, then Tillor. *Handy if the internet drops for a moment.* **API First**: always ask Tillor directly. Default is **Local First**. |
| **<Term term="API">API</Term> ACL timeout** | How long (in milliseconds) the controller waits for Tillor before it switches over. Default is 1000 ms (1 second). |

<Callout type="info" title="When to use Local First?">
Choose **Local First** if you want the controller to keep working during temporary internet outages. The controller stores access rights locally.
</Callout>

## Internet configuration [#internetconfiguratie]

| Setting | Meaning |
| ---------- | --------- |
| **Primary network connection** | **WiFi** or **Ethernet** (network cable). This is the connection the controller tries first. Default is **WiFi**. |
| **Wi-Fi networks** | The list of Wi-Fi networks the controller knows, with a maximum of 8. See [Setting up Wi-Fi networks](/controllers/wifi-netwerken). |

## Update configuration [#updateconfiguratie]

See [<Term term="firmware">Firmware</Term> updates](/controllers/updates) for a full explanation of update frequency, the update window and skipping OTA updates.

| Setting | Meaning |
| ---------- | --------- |
| **Update frequency** | How often the unit checks for a new version: **Hourly**, **Daily** or **Weekly**. |
| **Update period from / Update period to** | *When may the unit update?* E.g. 02:00-04:00 = only at night. |
| **Skip <Term term="OTA">OTA</Term> updates** | Set to **Yes** if the unit may no longer fetch updates. *Handy temporarily, but normally you leave this on No.* |

## Relay control [#relais-aansturing]

The <Term term="relais">relay</Term> is a switch in the unit. *You can use it, for example, to open or close an access point.*

| Setting | Meaning |
| ---------- | --------- |
| **Relay type** | Currently only **Internal** is supported. |
| **Relay port** | Port number of the relay. Default is 1. |

## See also [#zie-ook]

<Cards>
  <Card title="Setting up Wi-Fi networks" href="/controllers/wifi-netwerken" description="Networks and priority" />
  <Card title="Firmware updates" href="/controllers/updates" description="Update window and OTA settings" />
  <Card title="Screen messages" href="/controllers/troubleshooting/scherm" description="What the controller's screen shows" />
</Cards>


# Screen messages (/en-GB/controllers/troubleshooting/scherm)

The controller has a round <Term term="scherm">touchscreen</Term>. It shows in plain language what the controller is doing: a title, a line of explanation below it and a coloured border. *So you no longer need to remember colours: it simply says it.* Below you find every message and what to do about it.

## Ready for use [#klaar-voor-gebruik]

| On the screen | Meaning |
| ------------- | --------- |
| **Scan QR** and **Scan your tag**, with **Amount due** and an amount | The controller is ready. The guest holds a tag against the screen or scans the QR code with a mobile phone. |
| QR code greyed out and crossed through | The controller temporarily has no connection with Tillor. Paying with a tag keeps working, paying online via the QR code does not for a while. |

## Scanning a tag [#een-tag-scannen]

You scan an <Term term="NFC">NFC</Term> tag by briefly holding it against the screen, as with contactless payment.

| On the screen | Meaning |
| ------------- | --------- |
| **One moment** - Processing payment | The tag has been read, the controller is asking Tillor whether it is allowed. Keep the tag against the screen a little longer. |
| **Payment successful!** with the amount charged and the balance | Paid. The shower or device starts. |
| **Welcome** with the guest's name | Access granted, at a door or facility without payment. |

If a tag is refused, the reason is shown on the screen:

| On the screen | What is going on | What to do |
| ------------- | --------------------- | ---------- |
| **Tag not recognised** - This tag does not belong here | The tag is not from your park. | Give the guest a tag from the park. |
| **Tag not recognised** - This is not a valid tag | The controller cannot read this type of tag. | Use a tag you received through Tillor. |
| **Scan failed** - Tag not read properly | The tag was removed too quickly. | Hold the tag against the screen again, a little longer. |
| **Payment refused** - No access | The tag may not use this controller. | Check the tag's access group in Tillor. |
| **Payment refused** - Tag not linked | The tag is not yet linked to a customer. | Link the tag to the customer in Tillor. |
| **Payment refused** - Insufficient balance | There is too little on the tag. The balance is shown. | Top up the tag at reception. |
| **Server unreachable** | The payment could not be processed. | Try again later; see [Connection problems](/controllers/troubleshooting/verbinding). |
| **Failed to update tag** | The balance could not be saved on the tag. | Hold the tag against the screen again and leave it there until the message disappears. |

<Callout type="info" title="One scan per presentation">
Leaving the tag against the screen has no effect: each presentation counts as one scan. If you want to scan again, remove the tag and hold it against the screen again.
</Callout>

## Starting up and connecting [#opstarten-en-verbinden]

| On the screen | Border | Meaning | What to do |
| ------------- | ---- | --------- | ---------- |
| **Connecting...** | Blue | The controller is starting up and looking for a connection to the internet and to Tillor. | Wait 1-2 minutes. |
| **Set up Wi-Fi** - Choose a Wi-Fi network on the screen | Purple | The controller does not have a network yet. | Tap **Set up Wi-Fi** and choose your network; see [Setting up Wi-Fi on the screen](/controllers/troubleshooting/verbinding#wifi-instellen-op-het-scherm). |
| **Set up Wi-Fi** - Wi-Fi credentials rejected | Purple | The password is not (or no longer) correct. | Enter the password again on the screen. |
| **Activate controller** - Activate device … in Tillor | Purple | The controller is waiting for <Term term="adoptie">adoption</Term>. | In Tillor go to **Controllers** and click **Approve** (✓). |
| **Connection lost** - trying again | Red | The internet connection is gone. The controller tries again by itself. | See [Connection problems](/controllers/troubleshooting/verbinding#verbinding-verbroken). |
| **Connection lost** - Offline for too long | Red | The controller has been without a connection for too long. Payments are off until the connection is back. | Restore the network connection. |

## Updates and restarting [#updates-en-herstarten]

| On the screen | Border | Meaning |
| ------------- | ---- | --------- |
| **Update** with a percentage | Amber | A <Term term="firmware">firmware</Term> update is being downloaded and installed. Leave the power on. |
| **Restarting** | Yellow | The controller is restarting, after an update or because you clicked **Reboot controller** in Tillor. |

## Faults [#storingen]

| On the screen | Meaning | What to do |
| ------------- | --------- | ---------- |
| **Tag reader unavailable** | The tag reader does not start. The controller tries to recover it by itself. | Wait a minute. If the message stays, [restart the controller](/controllers/controller-beheren#een-controller-herstarten). |
| **No connection** - Connecting to the controller | The screen receives no signal from the rest of the controller. | Restart the controller. If it stays that way, contact Tillor support. |
| Screen stays black | The controller has no power. | Check the power supply and the cabling. |

## See also [#zie-ook]

<Cards>
  <Card title="Connection problems" href="/controllers/troubleshooting/verbinding" description="Wi-Fi, Tillor connection and adoption" />
  <Card title="Controller settings" href="/controllers/settings" description="ACL, network, updates and relays" />
</Cards>


# Connection problems (/en-GB/controllers/troubleshooting/verbinding)

If the controller does not connect properly, its <Term term="scherm">screen</Term> tells you where it goes wrong. Below you will find what each message means and what to do. All messages are listed under [Screen messages](/controllers/troubleshooting/scherm).

## Set up Wi-Fi on the screen [#wifi-instellen-op-het-scherm]

If the screen says **Set up Wi-Fi**, the controller does not have a network yet. With a network cable (Ethernet) you do not have to do anything; for Wi-Fi you set up the network on the controller itself:

1. Tap **Set up Wi-Fi**
2. Choose your network from the list. Each network shows its signal strength: green is good, orange is fair, red is weak
3. Type the password on the on-screen keyboard and confirm
4. The screen shows **Connected** - Wi-Fi is set up

If your network is not listed, tap search again. If you want to change the network later, press and hold the screen while the controller is idle, or change it in the [settings](/controllers/settings#internetconfiguratie) in Tillor.

| Message | Solution |
| ------- | -------- |
| **Connection failed** - Check the password | Type the password again; mind the capital letters. |
| **Connection failed** - Network not found | Move the controller closer to the access point or choose another network. |
| **Connection failed** - Searching for networks failed | Tap search again. If it stays like this, restart the controller. |
| **Set up Wi-Fi** - Wi-Fi credentials rejected | The saved password is no longer correct. Enter it again on the screen. |

## Activate controller [#controller-activeren]

**Meaning:** The controller is waiting for <Term term="adoptie">adoption</Term> - it is not linked to Tillor yet. *The box is ready, but does not know yet which organization it belongs to.* The screen shows **Activate controller** with the number of the device.

**Solution:**
1. In Tillor, go to **Controllers**
2. Find the **Pending approval** row with the same number (the <Term term="eFuse ID">eFuse ID</Term>)
3. Click **Approve** (✓) to link the controller to your organization

## Connection lost [#verbinding-verbroken]

**Meaning:** The internet connection is gone. The controller automatically tries to reconnect. *The box has lost contact with Tillor and is trying to get it back.*

As long as the interruption is short, guests can keep paying with their tag; the QR code is then greyed out and crossed through. If it says **Offline too long**, payments are switched off until the connection is back.

In Tillor, the controller shows as offline after about 35 seconds without contact. After 5 minutes the Tillor team receives a notification.

**Possible causes:**
- **Wi-Fi has dropped** - check whether the Wi-Fi network is reachable
- **Internet outage** - the controller cannot reach Tillor
- **Tillor is temporarily unavailable**

**Solution:**
- Wait a few minutes - the controller tries to reconnect by itself
- Check whether other devices on the same network have internet
- Check the controller's [Wi-Fi settings](/controllers/settings) (network name, password)
- Make sure the controller is within range of the Wi-Fi access point, or use a network cable

## Screen stays on Connecting... [#scherm-blijft-op-verbinden]

**Meaning:** The controller is still starting up or connecting. Under the title you see the step it is at, for example *Setting up internet connection* or *Checking for updates*.

**Solution:**
- Wait 1-2 minutes - starting up takes a while
- If it stays on *Setting up internet connection*: check the network cable or [set up Wi-Fi again](#wifi-instellen-op-het-scherm)
- Check whether the Wi-Fi signal is strong enough

## Controller does not appear in Tillor [#controller-verschijnt-niet-in-tillor]

**Meaning:** The controller is not visible for adoption yet.

**Possible causes:**
- The controller has no internet connection (cannot reach Tillor)
- The controller is still starting up
- You open Tillor from a different network than the one the controller is connected to - adoption requests are then sometimes not visible

**Solution:**
1. Check that the controller has power and the screen is on
2. Look at what the screen shows: at **Set up Wi-Fi** or **Connecting...** it is not online yet
3. Wait until the screen shows **Activate controller** and the **Pending approval** row appears in the list - this can take a while
4. Open Tillor from the same network as the controller, or contact support
5. Refresh the Controllers page in Tillor (new requests also appear automatically)

## Adoption fails or credentials are rejected [#adoptie-mislukt-of-credentials-worden-geweigerd]

<Term term="adoptie">Adoption</Term> is linking the controller to your organization; <Term term="credentials">credentials</Term> are the connection details that go with it.

**Meaning:** Linking to Tillor did not succeed. *The box could not be linked to your organization.*

**Solution:**
- Check that the controller's clock is correct (a large time difference can block the link)
- After a firmware flash or a new key, the controller has to be approved again
- Try the adoption again via **Approve** (✓)
- Contact support if the problem persists - they have access to the logs

## OTA update hangs or fails [#ota-update-blijft-hangen-of-faalt]

An <Term term="OTA">OTA</Term> update is a <Term term="firmware">firmware</Term> update over the internet. During an update the screen shows **Update** with a percentage.

**Meaning:** The firmware update was not completed. *The box tried to install new software, but it did not go well.*

**Solution:**
- Wait until the [<Term term="updatevenster">update window</Term>](/controllers/updates) is active - updates only take place within that window
- Check that the controller has a stable internet connection
- Temporarily switch on [Skip OTA updates](/controllers/updates#ota-updates-overslaan) if you first want to get the controller stable

## See also [#zie-ook]

<Cards>
  <Card title="Screen messages" href="/controllers/troubleshooting/scherm" description="What does the message on the screen mean?" />
  <Card title="Controller settings" href="/controllers/settings" description="Configure Wi-Fi and network" />
</Cards>


# Firmware updates (/en-GB/controllers/updates)

A controller fetches new software over the internet by itself, just like your phone. That software is called <Term term="firmware">firmware</Term>. You decide **when** and **how often** it may do that. By default it checks daily whether there is something new. If you want to start an update straight away, you do that from the controller page, see [Managing a controller](/controllers/controller-beheren#bijwerken-naar-een-nieuwe-versie).

## Update frequency [#updatefrequentie]

The controller periodically checks whether a new firmware version is available:

| Option | Meaning |
| ------ | ------- |
| **Hourly** | Checks for updates every hour. |
| **Daily** | Checks once a day (default). |
| **Weekly** | Checks once a week. |

After the check, an update is only carried out if there is a newer version. If you have set an update window, the current time must also fall within that window. *So: the box does check whether there is something new, but only installs it at the times you have set.*

## Update window [#updatevenster]

The update window is the time window in which the controller may update. If you have filled in **Update period from** and **Update period to**, updates are only carried out within those times. *Put simply: you choose when the box may update - for example only at night.*

**Example:** If you set **Update period from** to 02:00 and **Update period to** to 04:00, an update only takes place between 02:00 and 04:00. This prevents the controller from restarting in the middle of the day during busy hours.

### Setting it up [#instellen]

1. Go to <UIPath>Controllers > Overview > [controller name]</UIPath>
2. Scroll to **Update configuration**
3. Choose **Update frequency** (Hourly, Daily or Weekly)
4. Fill in **Update period from** (e.g. 02:00)
5. Fill in **Update period to** (e.g. 04:00)
6. Click **Save**

## Skip OTA updates [#ota-updates-overslaan]

<Term term="OTA">OTA</Term> stands for Over-The-Air: updates over the internet. If you set **Skip OTA updates** to **Yes**, the controller no longer installs new firmware. The controller stays on the current version. *In other words: the box no longer updates itself via OTA.*

**When to use it?**

- Temporarily, if you do not want any changes during a busy period
- For test or demo controllers that have to stay on a fixed version

<Callout type="info" title="Recommendation">
Leave **Skip OTA updates** on **No** by default. Updates often contain improvements and security fixes.
</Callout>

## What happens during an update? [#wat-gebeurt-er-tijdens-een-update]

1. The controller detects a new <Term term="firmware">firmware</Term> version
2. The firmware is downloaded
3. The screen shows **Update** with a percentage - the controller is being updated
4. The controller restarts automatically; the screen shows **Restarting**
5. After the restart the new version is active

## What happens next? [#wat-gebeurt-er-daarna]

- An update only starts if there is a newer version and the time falls within your update window.
- While updating and restarting, the screen shows **Update** and **Restarting**. So plan the window at night.
- If you set **Skip OTA updates** to **Yes**, the controller stays on its current version until you switch it back.

## Problems? [#problemen]

<Accordions>
<Accordion title="The controller does not update">
Check that **Skip OTA updates** is set to **No** and that the time falls within your update window. Also check the controller's internet connection. More at [OTA update hangs or fails](/controllers/troubleshooting/verbinding#ota-update-blijft-hangen-of-faalt).
</Accordion>
<Accordion title="The screen stays on Update">
Leave the power on and wait a few minutes. If it stays like this, restart the controller and contact support.
</Accordion>
<Accordion title="Tillor says: OTA update failed">
The update could not be started. Check that the controller is online and try again.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Controller settings" href="/controllers/settings" description="Overview of all settings" />
  <Card title="Screen messages" href="/controllers/troubleshooting/scherm" description="Update and Restarting" />
</Cards>


# Setting up Wi-Fi networks (/en-GB/controllers/wifi-netwerken)

A controller can know several Wi-Fi networks and switches to the best one by itself. That is handy if your park has its own access point in different places. You set them up on the controller's page. If the controller still has no network, it is better to set up Wi-Fi on the screen itself, see [Set up Wi-Fi on the screen](/controllers/troubleshooting/verbinding#wifi-instellen-op-het-scherm).

Before you start:

- The controller has been approved, see [Linking a controller](/controllers/controller-koppelen).
- You know the name (SSID) and password of each network. An open network has no password.

## Adding networks [#netwerken-toevoegen]

<Steps>
<Step>
### Open the controller [#open-de-controller]
Go to <UIPath>Controllers > Overview</UIPath> and click the controller. Scroll to **Wi-Fi networks**.
</Step>
<Step>
### Add a network [#voeg-een-netwerk-toe]
Click **Add network** and fill in the **Network name (SSID)** and the **Password**. Leave the password empty for an open network. Repeat this for each network.
</Step>
<Step>
### Put them in order [#zet-ze-in-volgorde]
Drag a row by the handle on the left. The order is the priority: the controller tries the networks it has in range from top to bottom.

<DocScreenshot src="/screenshots/controllers/controller-wifi-networks.png" alt="Wi-Fi networks with two networks in order of priority" />
</Step>
<Step>
### Click Save [#klik-op-opslaan]
The **Save** button is at the bottom of the form. Tillor then sends the list to the controller.
</Step>
</Steps>

You remove a network with the minus button (**Remove network**).

## What happens next? [#wat-gebeurt-er-daarna]

- The controller checks each network separately. If the first network drops out or the password is wrong, it uses the next one.
- On the detail page, under **Known Wi-Fi networks, in priority order**, you can see how each network is doing:

| Status | Meaning |
|---|---|
| <Status tone="success">Connected</Status> | The controller is using this network now. |
| <Status>Verified</Status> | The network works, but the controller is using another network now. |
| <Status tone="info">Not verified yet</Status> | The controller has not been able to test this network yet. |
| <Status tone="warning">Failed</Status> | The network does not work. The reason is shown, for example a wrong password, network not found or no internet access. |

- For each network it says whether it is **in range** or **not in range**, sometimes with the signal strength in dBm. Networks that were entered on the screen are marked **added on the display**.
- If the list is empty, no networks have been set up in Tillor. Networks that someone added on the screen are kept on the controller.
- Older controllers that only know one network show a single message about the latest change instead, such as **Wi-Fi change not confirmed yet** or **Wi-Fi credentials rejected**. The controller then stays connected to the previous network.

## Problems? [#problemen]

<Accordions>
<Accordion title="Add network is greyed out">
A controller remembers at most 8 networks. Tillor says so with **A controller remembers at most 8 networks.** First remove a network you no longer need.
</Accordion>
<Accordion title="Tillor says: Enter a network name">
A row has no network name. Fill in the name or remove the row.
</Accordion>
<Accordion title="Tillor says: This network is already in the list">
Each network name may only appear once. Remove the duplicate row.
</Accordion>
<Accordion title="A network shows Failed">
Read the reason shown with the network. Check the name and the password. The controller tries again by itself and the other networks keep working.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Connection problems" href="/controllers/troubleshooting/verbinding" description="Wi-Fi and Tillor connection" />
  <Card title="Controller settings" href="/controllers/settings" description="Network preference and other settings" />
</Cards>


# Tillor Manual (/en-GB)

<HomeHero title="How do you do it in Tillor?">
  Task-by-task help for reception, administration and the technical team. Search for what you want to do, or start from your role.
</HomeHero>

<HomeSection title="What are you working on?" description="The most common tasks for each role.">

<RoleCard title="Reception" description="Welcome guests, check them in and answer questions." href="/reserveringen" icon={<ConciergeBellIcon />}>

- [Find or create a customer](/klantenbeheer)
- [Make a reservation](/reserveringen)
- [Check a guest in with an occupation](/bezettingen#een-bezetting-aanmaken)
- [Answer messages in the inbox](/inbox)

</RoleCard>

<RoleCard title="Administration" description="Invoices, payments and the link with your bookkeeping." href="/facturen" icon={<LandmarkIcon />}>

- [Create and book an invoice](/facturen/aanmaken-en-bewerken#een-factuur-aanmaken)
- [Record a payment](/facturen/betalingen-registreren)
- [Extend an occupation with an invoice](/bezettingen#facturatie-bezetting-verlengen)
- [Payment reports to your bookkeeping](/boekhouden/betalingsrapporten)

</RoleCard>

<RoleCard title="Technical team" description="Barriers, meters, controllers and tablets on site." href="/controllers" icon={<CpuIcon />}>

- [Open or close an access point](/toegangscontrole#toegangspunten-bedienen)
- [Link a meter to a terrain](/meterbeheer/meter-koppelen)
- [What does the message on the screen mean?](/controllers/troubleshooting/scherm)
- [Set up a kiosk](/mobiele-app/kiosk-inrichten)

</RoleCard>

<RoleCard title="Developers" description="Connect Tillor to your own systems or website." href="/ontwikkelaars" icon={<BracesIcon />}>

- [Create an API key](/ontwikkelaars/http)
- [Receive webhooks](/ontwikkelaars/webhooks)
- [Real-time events over SSE](/ontwikkelaars/sse)
- [Connect AI tools with MCP](/ontwikkelaars/mcp)

</RoleCard>

</HomeSection>

<HomeSection title="More">

<HomeLink title="New to Tillor?" description="Sign in, find your way and set up your park." href="/aan-de-slag" icon={<RocketIcon />} />

<HomeLink title="In practice" description="Four worked examples that combine several modules." href="/praktijk" icon={<RouteIcon />} />

<HomeLink title="Glossary" description="The words you come across in Tillor, briefly explained." href="/begrippen" icon={<RocketIcon />} />

<HomeLink title="What's new" description="Recent changes in Tillor, by month." href="/wat-is-nieuw" icon={<SparklesIcon />} />

<HomeLink title="Tablets and kiosks" description="The Tillor app on tablets at reception or outdoors." href="/mobiele-app" icon={<TabletSmartphoneIcon />} />

<HomeLink title="System status" description="Is everything running? See incidents and maintenance." href="https://status.tillor.eu" icon={<ActivityIcon />} />

</HomeSection>


# Sending a command to a tablet (/en-GB/mobiele-app/acties-op-afstand)

On the right of the device page you find the **Remote actions** panel, whichever tab you have open. There you send a command to the device and request a screenshot. What the device reports itself you can read under [Diagnostics and history](/mobiele-app/diagnose-en-geschiedenis).

<Requires permission="Edit settings" />

Before you start:

- The device must be connected. A command travels over the live connection with the app. If the device is offline, the panel says **The device is offline: commands only arrive when it is connected again.** Tillor does report that the command has been sent, but the tablet does not see it.
- **Restart device** only works if Tillor is the owner of the tablet. See [Setting up a kiosk](/mobiele-app/kiosk-inrichten).

## Sending a command [#een-opdracht-versturen]

<Steps>
<Step>
### Open the device [#open-het-toestel]
Go to <UIPath>Settings > Tablets & kiosks</UIPath> and click the device's row.
</Step>
<Step>
### Choose the command [#kies-de-opdracht]
In the **Remote actions** panel, click the command. You get the message **Sent to the device**, or **Could not reach the device** if it could not be sent.

<DocScreenshot src="/screenshots/tablets/remote-actions.png" alt="Remote actions and the Screenshot block" />
</Step>
</Steps>

The commands:

- **Show name on screen** shows the device's name in large letters for a moment. Handy if two tablets are side by side and you want to know which one you have open.
- **Play test sound** plays the notification sound, at the volume of the **Receipts and sound** tab.
- **Wake screen** takes the device out of night rest or out of **Put screen to sleep**.
- **Put screen to sleep** turns the screen black, also outside night rest.
- **Sleep for 30 seconds** does the same and then wakes up by itself. This lets you check that the screen comes back on, without waiting until the morning.
- **Restart device** restarts the tablet. On a tablet that Tillor does not own, the button stays greyed out.
- **Install update** installs an app update that is already waiting.
- **Restart app** restarts only the Tillor app, not the tablet.

## Requesting a screenshot [#een-schermafbeelding-opvragen]

<Steps>
<Step>
### Click Request screenshot [#klik-op-schermafbeelding-opvragen]
In the **Screenshot** block, this sends the request to the tablet.
</Step>
<Step>
### Wait for the image [#wacht-op-het-beeld]
Tillor waits a short time and refreshes the image as soon as the tablet has uploaded it. Below the picture it says when it was taken.
</Step>
</Steps>

The image is what the app is showing at that moment: home screen, slideshow, receipt or the sleep screen. It is not live video.

## What happens next? [#wat-gebeurt-er-daarna]

- The tablet carries out the command straight away. Every command except the sleep commands also wakes the screen.
- Every command is added to the [device's history](/mobiele-app/diagnose-en-geschiedenis#geschiedenis).
- A screenshot stays in the panel until you request a new one.

## Problems? [#problemen]

<Accordions>
<Accordion title="Tillor says Could not reach the device">
The command could not reach the device. Usually it is offline. Wait until the status is **Connected** again and send it again.
</Accordion>
<Accordion title="The Restart device button is greyed out">
Tillor is not the owner of the tablet. First set it up as described in [Setting up a kiosk](/mobiele-app/kiosk-inrichten). Until then you can only use **Restart app**.
</Accordion>
<Accordion title="No screenshot arrives">
The device is offline or the app is too old. In the latter case Tillor tells you beforehand: **The app on this device is too old for screenshots.** Install a newer version. As long as you have never requested an image, it says **No screenshot requested yet.**
</Accordion>
<Accordion title="The screen stays black after Wake screen">
Waking remotely only works if the app is also on the battery exception list. See [Battery](/mobiele-app/kiosk-inrichten#batterij-de-app-niet-laten-inslapen).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Diagnostics and history" href="/mobiele-app/diagnose-en-geschiedenis" description="What the device reports itself" />
  <Card title="Managing a tablet or kiosk" href="/mobiele-app/tablets-en-kiosken" description="Sending settings" />
</Cards>


# Diagnostics and history (/en-GB/mobiele-app/diagnose-en-geschiedenis)

Below the **Remote actions** panel are two blocks that help you check a tablet: **Diagnostics** (what the device reported last time) and **History** (the log). You can send a command in the same panel, see [Sending a command to a tablet](/mobiele-app/acties-op-afstand).

<DocScreenshot src="/screenshots/tablets/diagnostics.png" alt="Diagnostics and history on the device page" />

## Diagnostics [#diagnose]

**Diagnostics** is the device's last report, not a live measurement. A dash means the app did not send that item.

| Item | Meaning |
|---|---|
| **Last seen** | When the device last had contact |
| **Connection** | Wi-Fi or mobile |
| **Screen** | **On** or **Asleep** |
| **Free storage** | Free space on the tablet, in GB |
| **Device language** and **Time zone** | The language and time zone of Android or iOS. This is not the language you chose for the app on the **Device** tab |
| **Build**, **Runtime version** | Which version of the app is on the tablet |
| **Last app update** and **Last update check** | When the app was last updated or checked |
| **Update error** | Appears if the last check or installation failed |
| **Registered** | When this device first appeared in the list |

## History [#geschiedenis]

**History** shows per device:

- when the device signed in
- when you sent settings or a command
- when the app was updated
- when the device went offline and when it came back online

The log refreshes by itself. **No events yet.** means nothing has been recorded yet.

## Notifications [#meldingen]

An offline notification or a battery notification only comes if **Notifications** on the **Device** tab is switched on, and not during night rest.

- Offline notification: the device has reported nothing for 10 minutes.
- Battery notification: below 15% without a charger. Tillor does not send them again until the device has been on the charger again or has clearly charged up.

The notification goes to the people who manage the settings. See [Notifications](/notificaties).

## See also [#zie-ook]

<Cards>
  <Card title="Sending a command to a tablet" href="/mobiele-app/acties-op-afstand" description="Waking, restarting and a screenshot" />
  <Card title="Device settings" href="/mobiele-app/toestelinstellingen" description="The Device tab with Notifications" />
</Cards>


# Overview (/en-GB/mobiele-app)

The Tillor app runs on a tablet, kiosk or phone at your park, for **iOS** and **Android**. Guests and colleagues see the home screen, receipts and signing requests on it. From Tillor in your browser you send settings and commands to those devices. A tablet that has to stay a kiosk is set up via [Setting up a kiosk](/mobiele-app/kiosk-inrichten).

<Callout type="warn" title="Not a full web app">
The app does not replace Tillor in your browser. Managing reservations, creating invoices or registering payments is done in the browser.
</Callout>

## How does this fit together? [#hoe-hangt-dit-samen]

A device appears in Tillor by itself as soon as someone opens the app and logs in. What you then set in Tillor goes to the device over the live connection. The other way round, the device reports to Tillor regularly, so you can see whether it is still connected.

```mermaid
flowchart LR
  A[Someone opens the app<br/>and logs in] --> B[The device is in<br/>Settings > Tablets & kiosks]
  B --> C[You choose settings<br/>and click Save and push]
  C --> D[The tablet applies them]
  E[You send a receipt,<br/>PDF or signing request] --> D
  D --> F[The device reports battery,<br/>connection and version back]
  F --> B
```

If a device is offline, settings and commands only arrive when it is connected again. See [Tablets and kiosks](/mobiele-app/tablets-en-kiosken).

<Callout type="info" title="Good to know">
- A new device is in the list within a minute after someone has logged in.
- Tillor reports a device as offline after 10 minutes without a message. This only happens if **Notifications** is switched on and not during night rest.
- The battery notification comes below 15% without a charger.
- A slideshow has at most 20 photos. You can put six extra buttons on the home screen.
- There is no separate app password. You log in as you do in the browser, with Microsoft, Google or Apple.
</Callout>

## Installing the app and logging in [#de-app-installeren-en-inloggen]

Your organization shares the installation file or the link (internal build, TestFlight or the app store, depending on your rollout). If you do not have access yet, ask your administrator or Tillor support.

1. Open the app after installing it.
2. Log in with **Microsoft**, **Google** or **Apple**. It is the same account as in the browser, see [Logging in](/inloggen).
3. Choose your organization if you have more than one.

## What the app can do [#wat-de-app-kan]

- **Show PDFs and images**: straight on the home screen as soon as Tillor sends a document to the device.
- **Scan prepaid cards**: read an NFC card and view the card and customer details.
- **Play payment sounds**: a sound signal when an invoice is paid.
- **Kiosk**: keep the screen on, adjust the brightness and show your organization's logo.

## What Tillor sees of the device [#wat-tillor-van-het-toestel-ziet]

The app regularly sends the name, model, operating system, app version, battery and network connection (Wi-Fi or mobile) to Tillor. You see this in the list of devices and on the device page. Under **Account** > **Active sessions** you find the same devices as app sessions, with **App metadata**. There you can also end a session.

## Problems? [#problemen]

<Accordions>
<Accordion title="The app does not connect">
Check the Wi-Fi or the mobile network, and whether you are logged in to the right organization. Update the app to the latest version. If that does not help, log out and in again. If it keeps going wrong, contact your administrator.
</Accordion>
<Accordion title="The device is not in the list">
Open the app, log in and choose the right organization. The device appears within a minute under **Settings** > **Tablets & kiosks**. If you see **No devices yet** there, no device has signed in yet.
</Accordion>
</Accordions>

## Terms [#begrippen]

- **Tablet**: a tablet with the Tillor app, for example at reception.
- **Kiosk**: a tablet that is locked to the Tillor app, so guests cannot leave it.
- **Device**: every installation of the app that is in Tillor, whatever the type.
- **Night rest**: the hours in which the screen goes off or black.
- **Screen lock**: a pattern or PIN on the tablet itself, which is something different from the kiosk lock.

More explanation is in the [glossary](/begrippen).

## See also [#zie-ook]

<Cards>
  <Card title="Tablets and kiosks" href="/mobiele-app/tablets-en-kiosken" description="Devices in the list, saving and pushing settings" />
  <Card title="Setting up a kiosk" href="/mobiele-app/kiosk-inrichten" description="Locking down an Android tablet" />
  <Card title="Device settings" href="/mobiele-app/toestelinstellingen" description="All settings per tab" />
  <Card title="Remote actions" href="/mobiele-app/acties-op-afstand" description="Waking, restarting and a screenshot" />
  <Card title="Logging in" href="/inloggen" description="Account access via Microsoft, Google or Apple" />
  <Card title="Controllers" href="/controllers" description="Hardware at your park" />
</Cards>


# Setting up a kiosk (/en-GB/mobiele-app/kiosk-inrichten)

With a kiosk you lock an Android tablet to the Tillor app. Guests see the home screen, a slideshow or a receipt, and do not get into the Android settings. After a power cut the tablet starts in Tillor again. This page walks through the one-off setup. The switches you set afterwards are covered under [Device settings](/mobiele-app/toestelinstellingen#kiosk).

Without the steps below you can switch on **Lock the app**, but then Android only uses screen pinning. That asks for a confirmation on the tablet and a guest can leave it. The status on the **Kiosk** tab then says **Screen pinning. This tablet is not set up as a kiosk device.**

The full lock only applies once Tillor is the owner of the device. On the **Kiosk** tab you read that as **Set up as a kiosk: the lock is complete.**

<Callout type="warn">
This works on Android. On iOS you can use the app as a kiosk for receipts and the home screen, but you cannot set it up as the device owner. The buttons under **Android management** then stay closed, with the message **Available once this tablet is a provisioned kiosk device.**
</Callout>

## Before you start [#voor-je-begint]

You need a computer with `adb` on it. That is a free program from Google that lets you control an Android tablet over a USB cable. It is a one-off job per tablet, meant for people who are a bit technical. If you cannot manage, ask Tillor support.

Before you start:

- Reset the tablet to factory settings, or use a tablet that does not have an extra Google account on it yet. Android refuses an app as owner as soon as there is already an account on the device.
- The Tillor app must be installed and logged in to your organization.
- In the Android settings, switch on **USB debugging** (Developer options).
- Connect the tablet to the computer with a cable. `adb devices` must show the tablet as `device`, not as `unauthorized`.

## Tillor as the owner of the tablet [#tillor-als-eigenaar-van-de-tablet]

The owner of an Android device may do things an ordinary app may not, such as really locking the tablet. Give Tillor that role with this command on the computer:

```bash
adb shell dpm set-device-owner eu.tillor.app/expo.modules.tillorkiosk.KioskAdminReceiver
```

If the command succeeds, Android replies that the owner has been set. If it fails with a message about accounts, remove the accounts or start again from a factory reset. You can only set this command once. Another owner requires a reset again.

Then in Tillor open **Settings** > **Tablets & kiosks**, set the type to **Kiosk** and save. On the **Kiosk** tab the **Kiosk device** tile should now be green. The other two tiles follow once you have pushed **App as home screen** and **Remove screen lock**. These tiles are explained under [Kiosk](/mobiele-app/toestelinstellingen#kiosk).

## Battery: not letting the app fall asleep [#batterij-de-app-niet-laten-inslapen]

Android, and certainly Xiaomi with HyperOS, drops the connection of an app that the system considers "asleep". The kiosk then goes offline in the middle of the night, even if the screen is supposed to be off because of night rest.

If Tillor is the owner, the app itself asks to switch off battery optimization. On most tablets that is a window where you tap **Allow**. On Xiaomi, HyperOS instead opens Tillor's battery page: choose **No restrictions** there. If you skip it, the app asks again after the next restart, and the connection stays unreliable at night.

No app can set this exception itself, not even as the owner of the device. So it remains one tap per tablet, or the command below.

If that window does not appear, set the exception from the computer during setup:

```bash
adb shell dumpsys deviceidle whitelist +eu.tillor.app
```

After that, the app should keep talking to Tillor in the background, even when the screen is off.

## Removing the screen lock [#schermvergrendeling-weghalen]

A pattern or PIN on the tablet means Android waits on the lock screen after every restart. The kiosk then stays black until someone comes by. The **Screen lock** tile warns about this: **A pattern or PIN has been set.**

1. Open the **Kiosk** tab.
2. Under **Android management**, set **Remove screen lock** to **On**.
3. Choose **Save and push**.

The tablet does not ask for it by itself. The lock disappears the next time someone enters the pattern or PIN, for example after a restart. After that, a restart ends in Tillor.

If you do not want to wait, remove the pattern yourself in the tablet's Android settings. The tile becomes **No pattern or PIN: a restart ends in Tillor.**

<Callout type="info" title="Xiaomi: navigation buttons">
As long as Tillor is the home screen, HyperOS switches the navigation from gestures to buttons. Tillor hides that bar until someone taps the home screen three times. If you choose **Unlock temporarily** in the app, you come back to Xiaomi's home screen. If you want gestures there again, set them in the Android settings.
</Callout>

## What to switch on afterwards [#wat-je-daarna-aanzet]

For a tablet in an enclosure at reception or the entrance, this is a useful set. Everything is on the **Kiosk** tab, unless stated otherwise.

| Setting | Position | Why |
| --- | --- | --- |
| **App as home screen** | On | The home button opens Tillor. Clock and battery stay visible. |
| **Lock the app** | On | Guests cannot leave the app. |
| **Hide system UI** | On | No notifications, no recent apps, no power menu. |
| **Lock down the device** | On | No factory reset, no safe mode, no USB transfer, no uninstalling. |
| **Stay on while charging** | On | The screen stays on during opening hours as long as the charger is plugged in. Night rest still takes priority. |
| **Automatic time** | On | Night rest follows the organization's clock, not a skewed tablet clock. |
| **Screen orientation** | Portrait or Landscape | On **Screen and sleep**, to suit the enclosure. **Default** is automatic rotation. |

**Lock the volume** holds the volume from the **Receipts and sound** tab, so a guest cannot use the buttons on the side.

Save and check the three tiles at the top of **Kiosk**. Green means the tablet reports it that way. A warning means that step has not succeeded yet.

## A new app version over USB [#een-nieuwe-app-versie-over-usb]

**Lock down the device** switches off USB debugging and file transfer. **Lock the app** keeps the tablet in the app, so an installation window cannot be confirmed.

Before you install a build over the cable:

1. Set **Lock the app** to **Off**.
2. Set **Lock down the device** to **Off**.
3. Choose **Save and push** and wait until the tablet releases the lock.
4. Install the new version. On Xiaomi, HyperOS asks on the tablet to confirm the installation via USB: tap **Install**.
5. Set both settings back to **On** and save again.

If you leave **Lock down the device** on, `adb` no longer sees the tablet. The battery exception and the ownership are kept with an ordinary update. A factory reset does not: then you start again at the `dpm` command.

## What happens next? [#wat-gebeurt-er-daarna]

- After a restart or power cut, the tablet starts in Tillor again, on the home screen.
- Guests cannot leave the app, and see no notifications or recent apps.
- The three tiles at the top of the **Kiosk** tab show what the tablet itself reports. After a change it can take a while before the tiles turn green, because the tablet reports every 30 to 60 seconds.
- An ordinary app update keeps the ownership and the battery exception. A factory reset does not.

## Problems? [#problemen]

<Accordions>
<Accordion title="The command says there are already accounts on the device">
Android refuses an owner as soon as there is an account on the tablet. Remove the accounts or start again from a factory reset.
</Accordion>
<Accordion title="adb devices shows unauthorized, or nothing">
Confirm the window on the tablet that asks for permission for the computer, and check that **USB debugging** is on. If **Lock down the device** is on, `adb` no longer sees the tablet: switch it off as in the USB update above.
</Accordion>
<Accordion title="The Kiosk tab says Screen pinning. This tablet is not set up as a kiosk device.">
Tillor is not yet the owner of the tablet, so Android only uses screen pinning. Run the owner command and then choose **Save and push**.
</Accordion>
<Accordion title="The buttons under Android management are closed">
The message **Available once this tablet is a provisioned kiosk device.** is shown with them. Set up the tablet as above, or use an Android tablet: this is not possible on iOS.
</Accordion>
<Accordion title="The kiosk is black after a restart">
There is a pattern or PIN on the tablet. Switch on **Remove screen lock** and enter the pattern or PIN once, or remove the lock in the Android settings.
</Accordion>
<Accordion title="The kiosk goes offline at night">
Android has put the app to sleep. Switch off battery optimization for Tillor, as under the Battery heading above.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Device settings" href="/mobiele-app/toestelinstellingen#kiosk" description="The switches on the Kiosk tab" />
  <Card title="Setting up night rest for the screen" href="/mobiele-app/nachtrust-instellen" description="Screen off at night" />
  <Card title="Managing a tablet or kiosk" href="/mobiele-app/tablets-en-kiosken" description="Sending settings" />
</Cards>


# Setting up night rest for the screen (/en-GB/mobiele-app/nachtrust-instellen)

A tablet that is on all night uses power and can cause screen burn-in. With night rest, the screen goes off or black during the hours the park is closed. The other screen options, such as dimming, are covered under [Device settings](/mobiele-app/toestelinstellingen#scherm-en-slaap).

<Requires permission="Edit settings" />

Before you start:

- If you want the screen to really go off and be able to wake up remotely, first set the tablet up as a kiosk and put the app on the battery exception list. See [Setting up a kiosk](/mobiele-app/kiosk-inrichten).
- If you choose your organization's opening hours, fill those in first. See [Organization](/gebruikers/organisaties#openingsuren).

## Setting up night rest [#de-nachtrust-instellen]

<Steps>
<Step>
### Open the Screen and sleep tab [#open-het-tabblad-scherm-en-slaap]
Open the device via <UIPath>Settings > Tablets & kiosks</UIPath> and click the **Screen and sleep** tile. Find the **Night rest** group.
</Step>
<Step>
### Choose the Night mode [#kies-de-nachtstand]
<Tabs items={["Fixed hours", "When the organization is closed"]}>
<Tab value="Fixed hours">
Choose **Fixed hours** and fill in **From** and **Until**. A schedule that runs past midnight, such as 22:00 to 07:00, is allowed.
</Tab>
<Tab value="When the organization is closed">
The screen follows your organization's opening hours. You change those in one place, and all devices follow.
</Tab>
</Tabs>
With **Off**, Tillor does not schedule any sleep.
</Step>
<Step>
### Choose the Sleep style [#kies-de-slaapstijl]
**Black overlay** puts a black layer over the picture, and a tap wakes it straight away. **Screen off** really switches the panel off.
</Step>
<Step>
### Click Save and push [#klik-op-opslaan-en-versturen]
At the top right of the group it says when the next sleep starts.
</Step>
</Steps>

<DocScreenshot src="/screenshots/tablets/tab-screen.png" alt="Screen and sleep tab, night rest from 22:00 to 07:00" />

## What happens next? [#wat-gebeurt-er-daarna]

- During night rest the screen goes off or black, even if **Keep screen on** is switched on. Night rest takes priority.
- Touching it wakes the screen briefly.
- At the end of the schedule the screen returns to normal.
- During night rest Tillor does not send a notification that the device is offline.
- If you want to wake the screen or put it to sleep outside the schedule, use [Remote actions](/mobiele-app/acties-op-afstand).

## Problems? [#problemen]

<Accordions>
<Accordion title="The screen does not wake at night via Wake screen">
**Screen off** works fully on a tablet that has been set up as a kiosk. Waking remotely only works if the app is also on the battery exception list. See [Battery](/mobiele-app/kiosk-inrichten#batterij-de-app-niet-laten-inslapen).
</Accordion>
<Accordion title="The tablet goes off too early or too late">
A wrong clock on the tablet shifts the schedule. On the **Kiosk** tab, switch on **Automatic time**, so the tablet follows the organization's clock.
</Accordion>
<Accordion title="The tablet is offline at night">
Android puts the app to sleep. Switch off battery optimization for Tillor, see [Setting up a kiosk](/mobiele-app/kiosk-inrichten#batterij-de-app-niet-laten-inslapen).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Setting up a kiosk" href="/mobiele-app/kiosk-inrichten" description="Device owner and battery" />
  <Card title="Remote actions" href="/mobiele-app/acties-op-afstand" description="Waking the screen or putting it to sleep" />
</Cards>


# Setting up the home screen and a slideshow (/en-GB/mobiele-app/startscherm-en-diavoorstelling)

The home screen is what guests see when there is no receipt on the screen: a welcome text, your logo, buttons and possibly a slideshow with posters or photos of the park. Here you set that up. Every individual setting with its limits is covered under [Device settings](/mobiele-app/toestelinstellingen#startscherm).

<Requires permission="Edit settings" />

Before you start:

- The device is in <UIPath>Settings > Tablets & kiosks</UIPath>, see [Managing a tablet or kiosk](/mobiele-app/tablets-en-kiosken).
- Photos are JPEG, PNG or WebP files, or an `https` link to an image.

## Changing the welcome text [#de-welkomsttekst-aanpassen]

<Steps>
<Step>
### Open the Home screen tab [#open-het-tabblad-startscherm]
Open the device and click the **Home screen** tile. The **Welcome title** (at most 60 characters) and **Welcome subtitle** (at most 120) fields are at the top.
</Step>
<Step>
### Fill in the text and push [#vul-de-tekst-in-en-verstuur]
Leave a field empty if the app may keep its own text. Click **Save and push**.
</Step>
</Steps>

<DocScreenshot src="/screenshots/tablets/tab-home.png" alt="Home screen tab, with Look and Buttons highlighted" />

## Adding a slideshow [#een-diavoorstelling-toevoegen]

<Steps>
<Step>
### Open the Slideshow and buttons tab [#open-het-tabblad-diavoorstelling-en-knoppen]
Click that tile. Under **Display** you choose how the photos appear.
</Step>
<Step>
### Choose the display [#kies-de-weergave]
<Tabs items={["As background", "Full screen when idle"]}>
<Tab value="As background">
The photos change behind the logo and the buttons, instead of your organization's background. Guests can tap the buttons at the same time.
</Tab>
<Tab value="Full screen when idle">
The photos take over the whole screen as soon as nobody touches the screen. A touch brings the home screen back. How long the wait lasts is set under **Start after**.
</Tab>
</Tabs>
</Step>
<Step>
### Add photos [#voeg-fotos-toe]
Click **Upload photo**, or paste an `https` address via **Add link**. You can add up to 20 photos. For a photo you can optionally add a caption of at most 80 characters.
</Step>
<Step>
### Set the timing [#stel-de-timing-in]
**Time per photo** ranges from 3 to 600 seconds. **Start after** from 10 to 3600 seconds. Under **Fit** you choose **Fill the screen** (the edges are cropped) or **Show whole photo** (with black edges).
</Step>
<Step>
### Click Save and push [#klik-op-opslaan-en-versturen]
The tablet shows the slideshow as soon as it has the settings.
</Step>
</Steps>

<DocScreenshot src="/screenshots/tablets/tab-content.png" alt="Slideshow and buttons tab, with the display and two extra buttons" />

## Adding extra buttons [#extra-knoppen-toevoegen]

Extra buttons are shortcuts on the home screen, for example to a site map or the guest network. You can have six.

<Steps>
<Step>
### Click Add button [#klik-op-knop-toevoegen]
An empty row appears.
</Step>
<Step>
### Fill in the button [#vul-de-knop-in]
Give it a text, a short description and a web address (`https` only). Choose an icon from the row and, under **When to show**, whether the button is always visible or only after a tap.
</Step>
<Step>
### Click Save and push [#klik-op-opslaan-en-versturen-1]
</Step>
</Steps>

The bin icon removes a button. **Let device decide** throws away the list from Tillor, so the tablet uses its own buttons.

## What happens next? [#wat-gebeurt-er-daarna]

- The tablet adjusts the home screen as soon as the settings arrive. A tablet that is offline does so as soon as it is connected again.
- If you set **Prepaid button** or **Settings button** to **After a tap**, the button disappears after the number of seconds you filled in under **Hide after**.
- A receipt, document or signing request that Tillor sends to the tablet appears over the home screen and disappears again.

## Problems? [#problemen]

<Accordions>
<Accordion title="Upload photo does not work and Tillor says Upload failed">
The file is not a JPEG, PNG or WebP, or the upload was interrupted. Try another photo, or use **Add link** with the address of the image.
</Accordion>
<Accordion title="I cannot add photos">
The buttons only appear if **Display** is not set to **Off**. If the list is at 20 photos, first remove one with **Remove photo**.
</Accordion>
<Accordion title="The slideshow does not start">
With **Full screen when idle** it only starts after the number of seconds under **Start after** without a touch. The default for a new slideshow is 60 seconds. Also check whether the tablet already has the new settings.
</Accordion>
<Accordion title="My button does not open anything">
The address has to start with `https`. Check that the link works in a browser.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Device settings" href="/mobiele-app/toestelinstellingen" description="All settings and limits" />
  <Card title="Managing a tablet or kiosk" href="/mobiele-app/tablets-en-kiosken" description="Sending settings" />
</Cards>


# Manage a tablet or kiosk (/en-GB/mobiele-app/tablets-en-kiosken)

Every tablet, kiosk or phone on which someone opens the Tillor app and chooses an organisation appears in Tillor. From there you can see whether the device is still connected and push the home screen, the sound and the kiosk lock to it. What you can set is described per tab under [Device settings](/mobiele-app/toestelinstellingen).

<Requires permission="Edit settings" />

Before you start:

- The device must have the Tillor app and someone must be logged in to your organisation. If not, you see **No devices yet**.
- Pushing settings is only allowed with the **Edit settings** permission.

## Push settings to a device [#instellingen-naar-een-toestel-sturen]

<Steps>
<Step>
### Open the list [#open-de-lijst]
Go to <UIPath>Settings > Tablets & kiosks</UIPath>. Each row is one installation of the app. You see the name, the type (**Tablet**, **Kiosk** or **Phone**), the model, the app version, the battery percentage and whether the device is connected. **Last seen** means the app has not reported anything for a while.

<DocScreenshot src="/screenshots/tablets/devices-list.png" alt="Settings > Tablets and kiosks with the kiosk Self-service kiosk" />
</Step>
<Step>
### Open the device [#open-het-toestel]
Click the device's row. At the top are the name and the status. Below that are a search box and a row of tiles, one per tab.

<DocScreenshot src="/screenshots/tablets/device-page.png" alt="Device page of Self-service kiosk with tab tiles and the save bar" />

A tile shows how many settings come from Tillor. **All left to the device** means you have not fixed anything on that tab yet. The **Remote actions** panel stays on the right, see [Remote actions](/mobiele-app/acties-op-afstand).
</Step>
<Step>
### Change the settings [#pas-de-instellingen-aan]
Choose a tab and change what you want. Almost every switch has three positions: **Device**, **On** and **Off**. **Device** keeps the choice made on the tablet itself. **On** and **Off** override that choice as soon as you save. Below the description it says what the app does when nobody has chosen anything, for example **Default: On**.
</Step>
<Step>
### Click Save and push [#klik-op-opslaan-en-versturen]
Nothing goes to the device until you click this. As long as something has been changed, the bar says **Unsaved changes** and the tab has a green dot. **Discard changes** resets the form to what is currently on the device.

Before and after a change you have not pushed yet:

<DocScreenshot src="/screenshots/tablets/device-page.png" alt="Before: device page without changes" />

<DocScreenshot src="/screenshots/tablets/device-page-unsaved.png" alt="After: a changed setting with Unsaved changes and a green dot on the tab" />
</Step>
</Steps>

## The same for all devices [#hetzelfde-voor-alle-toestellen]

If you have several devices of the same type, you do not need to set each one separately.

<Tabs items={["One device", "All devices of this type"]}>
<Tab value="One device">
Click **Save and push**. Only this device receives the settings.
</Tab>
<Tab value="All devices of this type">
Click **Apply to all kiosks** (or **tablets**, or **phones**, depending on the type). Tillor copies the settings of this device to the other devices of the same type and pushes them straight away, with the message **Settings copied to the other devices**. The name, the type and the alerts stay each device's own. The language is copied.
</Tab>
</Tabs>

## Search across all tabs [#zoeken-over-alle-tabbladen]

Not sure which tab a setting is on? The **Search settings** box searches all tabs at once. The tiles stay in place, but below them a list of matches appears, grouped by tab.

<DocScreenshot src="/screenshots/tablets/device-search.png" alt="Searching for brightness, with the matches from Screen and sleep" />

A search such as `brightness` shows the brightness rules of **Screen and sleep**, and below them other tabs that also contain the word. **Open tab** closes the search and opens that tab, so you see the rest of the group too. If nothing is found, it says **No settings match** your search term.

## Forget a device [#een-toestel-vergeten]

The three-dot menu at the top right of the device page contains **Forget device**. Use this for a tablet that is no longer in use.

<DocScreenshot src="/screenshots/tablets/device-menu.png" alt="Menu with Forget device" />

## What happens next? [#wat-gebeurt-er-daarna]

- Tillor reports **Settings pushed**. The tablet applies them straight away if it is connected. If it is offline, it receives them as soon as it makes contact with Tillor again. The app reports in every 30 to 60 seconds.
- The device page and the list show whether the device is connected. The device also reports its battery, app version and connection back, see [Diagnostics and history](/mobiele-app/diagnose-en-geschiedenis).
- Every change goes into the device's history and into your organisation's [activity log](/activiteitenlog).
- A forgotten device disappears from the list and the pushed settings go with it. If the app is still running on it and someone is logged in, it comes back within a minute, without those settings. You then have to set them again.
- If you turn **Alerts** on in the **Device** tab, the people who manage the settings receive a message when the device has been offline for 10 minutes or the battery drops below 15% without a charger.

## Problems? [#problemen]

<Accordions>
<Accordion title="I see No devices yet">
No tablet has registered yet. Open the Tillor app on the tablet, log in and choose the right organisation. The device appears within a minute.
</Accordion>
<Accordion title="Tillor says Could not save the settings">
Saving failed, often because of an unreliable connection or because you lack the **Edit settings** permission. Try again. If it still does not work, ask your administrator for the permission.
</Accordion>
<Accordion title="Tillor says Could not copy the settings">
**Apply to all kiosks** did not work. Click again. If it still fails, save the device with **Save and push** and open the other devices one by one.
</Accordion>
<Accordion title="The tablet does nothing with my change">
Check that the device is **Connected**. If it is offline, it applies the settings as soon as it makes contact again. If the switch is set to **Device**, the tablet decides for itself. Choose **On** or **Off** to override it.
</Accordion>
<Accordion title="The device is back after Forget device">
The app is still running and someone is logged in, so it registers again. Log out on the tablet if you really want to get rid of the device. Under **Account** > **Active sessions** you can end the app session.
</Accordion>
<Accordion title="Tillor says Use 4 to 6 digits">
The **Settings code** on the **Home screen** tab must consist of 4 to 6 digits, or be empty. Only then can you save.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Device settings" href="/mobiele-app/toestelinstellingen" description="What is on each tab" />
  <Card title="Set up a kiosk" href="/mobiele-app/kiosk-inrichten" description="Lock down an Android tablet so guests cannot leave the app" />
  <Card title="Remote actions" href="/mobiele-app/acties-op-afstand" description="Wake the screen, restart and take a screenshot" />
</Cards>


# Device settings (/en-GB/mobiele-app/toestelinstellingen)

Here you find all the settings of a device, per tab, with their defaults and limits. There are six, each a tile above the forms. How to get there, how search works and when something goes to the device is described in [Manage a tablet or kiosk](/mobiele-app/tablets-en-kiosken). The home screen is covered step by step in [Set up the home screen and a slideshow](/mobiele-app/startscherm-en-diavoorstelling) and the night rest in [Set up a night rest for the screen](/mobiele-app/nachtrust-instellen).

Every rule has an icon, a short explanation and, where it makes sense, the app's default. Choose **Device** (or leave a number empty on **Default**) if the tablet may keep its own choice. **On** and **Off** override that choice.

Rules that only work on a provisioned kiosk show a warning as long as the tablet is not one yet: **Available once this tablet is a provisioned kiosk device.** Those steps are described in [Set up a kiosk](/mobiele-app/kiosk-inrichten).

## Home screen [#startscherm]

Welcome text, background and the buttons guests see when no receipt is on the screen.

### Welcome text [#welkomsttekst]

**Welcome title** (maximum 60 characters) and **Welcome subtitle** (maximum 120) appear at the top of the home screen. Leave a field empty if the app may keep its own text.

### Look [#uiterlijk]

<DocScreenshot src="/screenshots/tablets/tab-home.png" alt="Home screen tab, with Look and Buttons highlighted" />

**Look** (marker **1**):

- **Background photo** shows the organisation's background behind the logo. On by default.
- **Background darkening** is a percentage from 0 to 90. Default 45, so the logo and the buttons stay legible on a light photo.
- **Logo style** is **White silhouette** (the default) or **In color on a card**.

### Buttons [#knoppen]

**Buttons** (marker **2**):

- **Prepaid button** opens balance, top-up and paying with an NFC card. On by default.
- **Settings button** shows a button to the settings on the device itself. If it is off, you get there by tapping the home screen three times.
- **When to show** is **Always**, or **After a tap**. With **After a tap** you fill in **Hide after**, in seconds. After that the button disappears again until someone taps the screen.
- **Settings code** is 4 to 6 digits. The device asks for this code before its own settings open. Empty means no code. Anything other than 4 to 6 digits cannot be saved.

## Slideshow and buttons [#diavoorstelling-en-knoppen]

Photos that the home screen alternates, and extra buttons to a web page.

<DocScreenshot src="/screenshots/tablets/tab-content.png" alt="Slideshow and buttons tab, with the display mode and two extra buttons" />

### Slideshow [#diavoorstelling]

**Display** (marker **1**) has three positions:

- **Off** shows no photos.
- **As background** alternates the photos behind the logo and the buttons, instead of the organisation background.
- **Full screen when idle** takes over the whole screen as soon as nobody touches the screen.

As soon as the display is not on **Off**, you can add up to 20 photos. **Upload photo** accepts JPEG, PNG or WebP. **Add link** pastes an `https` address of an image. For each photo you can set a caption of up to 80 characters.

- **Time per photo** is how long each photo stays, from 3 to 600 seconds. A new slideshow starts at 10.
- **Start after** only applies to full screen: seconds without a touch before the slideshow starts, from 10 to 3600. A new slideshow starts at 60.
- **Fit**: **Fill the screen** crops the edges, **Show whole photo** keeps the whole photo with black borders. A new slideshow starts at **Show whole photo**.

A touch on a full-screen slideshow brings back the home screen.

### Extra buttons [#extra-knoppen]

**Extra buttons** (marker **2**) are shortcuts on the home screen, for example a map or the guest network. You can have six.

For each button you fill in the text on the button, a short description, the web address and an icon. You pick the icon from the row: map, website, information, calendar, food and drink, wifi, phone or tickets. **When to show** works the same as for the prepaid button: always, or only after a tap and then hide again.

**Add button** creates an empty row. The bin icon removes that button. **Let device decide** discards the list from Tillor, so the tablet uses its own buttons. As long as you have not saved any buttons yet, that sentence is also shown: no buttons have been set from Tillor.

## Screen and sleep [#scherm-en-slaap]

Brightness, rotation, colours and when the screen goes off at night.

### Brightness [#helderheid]

If you are looking for a setting, try `brightness` in the search box, see [Search across all tabs](/mobiele-app/tablets-en-kiosken#zoeken-over-alle-tabbladen).

- **Kiosk mode** keeps the screen on, with receipts, signing and brightness control. On by default on a tablet or kiosk, off on a phone.
- **Keep screen on** prevents the screen from falling asleep. On by default, off on a phone.
- **Dim when idle** goes to full brightness on a touch and dims afterwards. On by default, off on a phone.
- **Dim after** is the number of seconds without a touch, from 5 to 3600. Default 15.
- **Dimmed brightness** is the percentage in that dimmed state, from 0 to 100. Default 0.5%.

The night rest below takes precedence over **Keep screen on**: during the sleep hours the screen still goes off or black.

### Display [#weergave]

- **Screen orientation** is **Rotate automatically** (the default), **Portrait** or **Landscape**. Fix a kiosk in an enclosure, otherwise the image rotates when someone holds the tablet at an angle.
- **Appearance** is **Follow the device**, **Light** or **Dark**.

### Night rest [#nachtrust]

<DocScreenshot src="/screenshots/tablets/tab-screen.png" alt="Screen and sleep tab, night rest from 22:00 to 07:00" />

**Night mode** (marker **1**) has three positions:

- **Off** schedules no sleep.
- **Fixed hours** uses **From** and **To**. A schedule that runs past midnight, such as 22:00 to 07:00, is allowed. The screen goes off in that block, even if it should stay on the rest of the day. Touching it wakes it briefly.
- **When the organization is closed** follows the organisation's opening hours.

At the top right of the group it shows when the next sleep falls.

**Sleep style**:

- **Black overlay** lays a black layer over the image. The screen stays touchable, so a tap wakes it immediately.
- **Screen off** really switches the panel off. It wakes up at the end of the schedule, or from **Wake screen** under [Remote actions](/mobiele-app/acties-op-afstand). This works fully on a tablet that is provisioned as a kiosk device. Waking remotely only works if the app is also on the battery exception list, see [Battery](/mobiele-app/kiosk-inrichten#batterij-de-app-niet-laten-inslapen).

## Receipts and sound [#kassabonnen-en-geluid]

What the tablet does when Tillor sends a document, and which sounds it plays.

<DocScreenshot src="/screenshots/tablets/tab-sound.png" alt="Receipts and sound tab" />

### Receipts and documents [#kassabonnen-en-documenten]

Marker **1**:

- **Show receipts and documents** puts PDFs, images and signing requests on this device. On by default, off on a phone. Turn it off on a tablet that should only be a home screen and must not show receipts.
- **Clear after** is the number of seconds a receipt stays before the device removes it itself, from 5 to 900. Leave it empty to wait until Tillor clears the screen.

### Sound [#geluid]

Marker **2**. Everything below is on by default, volume at 100%.

- **Startup sound** plays when the app starts or restarts.
- **Sound for receipts and documents** plays when a receipt, image or signing request arrives.
- **Sound for online payments** plays when an invoice has been paid online, or by automatic transfer.
- **Low battery sound** plays a warning when the battery is almost empty and the charger is not connected.
- **Volume** is 0 to 100. On a kiosk you can fix this with **Lock the volume** on the **Kiosk** tab.

**Play test sound** is under [Remote actions](/mobiele-app/acties-op-afstand), not on this tab.

## Kiosk [#kiosk]

Only useful on Android. The setup (owner of the device, battery, USB) is described in [Set up a kiosk](/mobiele-app/kiosk-inrichten). This tab is where you set the switches afterwards.

<DocScreenshot src="/screenshots/tablets/tab-kiosk.png" alt="Kiosk tab with status tiles and lock" />

### Status [#status]

Three tiles (marker **1**) show what the tablet said in its last report. They are not settings.

- **Kiosk device** is green with **Provisioned kiosk: the lock is complete.** A warning means screen pinning (the app is not the owner) or that the app is not locked at all. A dash means this app version does not report the status yet.
- **Home screen** is green if Tillor is the home screen. Otherwise it says that Tillor is not yet, or that the app has not reported it yet.
- **Screen lock** warns if a pattern or PIN is set on the tablet. After a restart the device then keeps waiting at the lock screen. Green means a restart ends in Tillor.

### Lock [#vergrendeling]

Marker **2**. By default these three are off, until you turn them on yourself.

- **App as home screen** makes Tillor the home screen. Clock and battery stay visible. Android only, and only with an app build that supports this.
- **Lock the app** keeps the tablet in the Tillor app. On a provisioned kiosk a guest cannot leave it. Without that setup Android falls back to screen pinning: someone at the tablet has to confirm it, and it can be exited.
- **Hide system UI** removes notifications, recent apps and the power menu. Clock and battery stay. This only works once the tablet is provisioned as a kiosk device.

### Android management [#android-beheer]

<DocScreenshot src="/screenshots/tablets/tab-kiosk-android.png" alt="Android management on the Kiosk tab" />

Everything in this group (marker **1**) only applies to a provisioned kiosk. On any other device you see the warning at every rule and the buttons are off. The switches are off by default. The two numbers are empty: the tablet then keeps its own brightness and timeout.

- **Lock down the device** blocks factory reset, safe mode, new users, USB transfer, uninstalling and force stop. Turn this off before you install an update over USB.
- **Remove screen lock** removes the pattern or PIN. It takes effect as soon as that pattern or PIN has been entered one more time.
- **Stay on while charging** keeps the screen on during opening hours as long as the charger is connected. The night rest still switches it off.
- **Lock the volume** fixes the volume from **Sound**.
- **Updates while asleep** installs system updates while the screen sleeps, and postpones them as long as the tablet is in use.
- **Automatic time** requires automatic date, time and time zone, so that sleep follows the opening hours.
- **Screen brightness** is a fixed brightness of the tablet itself, from 1 to 100, with automatic brightness off. Leaving it empty keeps the tablet's setting.
- **Screen timeout** is the number of seconds (15 to 3600) after which Android switches the screen off if the app does not keep it on. Leaving it empty keeps the tablet's setting.

## Device [#toestel]

Name, type, language and alerts. **Apply to all kiosks** copies the language to the other devices of the same type, and leaves the name, type and alerts alone.

<DocScreenshot src="/screenshots/tablets/tab-general.png" alt="Device tab with name, type, language and alerts" />

Marker **1**:

- **Name** is what you see in the list and on the device, for example `Self-service kiosk`. Maximum 80 characters.
- **Type** is **Tablet**, **Kiosk** or **Phone**. The type determines the text on **Apply to all …** and a few defaults: on a phone, kiosk mode, receipts, keep screen on and dimming start off.
- **Language** is the only list that collapses, because there are more options than fit in a row of buttons. **Default** follows the tablet's language. Otherwise you choose a language of the Tillor app. The names are shown in that language itself.
- **Alerts** notifies the people who manage the settings if this device has been offline for 10 minutes, or if the battery drops below 15% without a charger. During the night rest no offline alert is sent. Off by default.

<Callout type="info">
The language here is the language of the app on the tablet. You can see the language of the Android system under **Diagnostics**, as **Device language**.
</Callout>


# Automations (/en-GB/ontwikkelaars/automatiseringen)

Automations let Tillor carry out actions itself, such as creating tasks or calling your system. The user guide is at [Automations](/automatiseringen). This page describes what an integrator sees: the message from the **Send webhook** step, the **API request** to your own URL or to the Tillor API, and how a flow is built if you manage it through the API.

## Send webhook [#webhook-versturen]

The **Send webhook** step delivers a custom message to one of the organisation's [webhooks](/ontwikkelaars/webhooks). It is the same delivery as for ordinary webhook events, with the same signature.

### The message [#het-bericht]

The step does a `POST` with `Content-Type: application/json` and these headers:

| Header | Content |
|---|---|
| `X-Webhook-Event-ID` | A unique ID for this delivery. The value stays the same on new attempts, so you can deduplicate on it |
| `X-Webhook-Signature` | `sha256=<hex>`, the HMAC-SHA256 of the body with the webhook's signing secret |

The body has the same envelope as the webhook payload:

```json
{
  "event": "automation.invoice_unpaid",
  "data": {
    "invoice": "2026-0042",
    "amountOutstanding": 125.5
  },
  "timestamp": 1735689600000,
  "traceId": "0b0f7c0e-5d3c-4c1e-9b8a-7f1e2a3b4c5d",
  "triggeredBy": null
}
```

| Field | Description |
|---|---|
| `event` | The **Event name** you filled in in the step. Any text is allowed, the name does not have to be in the list of event keys |
| `data` | The **Payload** from the step, after the variables have been filled in, as JSON |
| `timestamp` | Unix time in milliseconds of the delivery |
| `traceId` | A random UUID per delivery. Unlike events from the system, this is not a trace ID of a Tillor action |
| `triggeredBy` | Always `null` |

There is no `spanId`. The webhook does not have to be subscribed to an event key: a message from an automation is always delivered to the chosen endpoint, as long as it exists and is enabled.

How to verify the signature is described under [Verifying the signature](/ontwikkelaars/webhooks#handtekening-verifiëren).

### Attempts and outcome [#pogingen-en-uitkomst]

Tillor makes up to 5 attempts within the step, waiting 1, 2, 4 and 8 seconds between them. An attempt counts as successful on a 2xx status. A target that is blocked, for example an internal address, also counts as a failed attempt.

- If one of the attempts succeeds, the flow continues through the **Succeeded** exit
- If all five fail, the flow continues through **Failed**. The message is then retried in the background according to the schedule under [Delivery behaviour and retries](/ontwikkelaars/webhooks#leveringsgedrag-en-retries). If such a later attempt succeeds, it no longer shows up in the run, because the run has already moved on

If the webhook no longer exists or is disabled, the step does not go through **Failed**. The run then stops with the status **Failed**.

## API request to your own URL [#api-verzoek-naar-een-eigen-url]

With **API request** and **Send to** set to **Custom URL**, an automation sends an HTTP request to your server.

| Part | Behaviour |
|---|---|
| Method | `GET`, `POST`, `PUT`, `PATCH` or `DELETE` |
| URL | Must start with `https://`. Variables are filled in encoded |
| Body | JSON. Not sent for `GET` and `DELETE`. With a body, Tillor sets `Content-Type: application/json` |
| Headers | Free to choose. The values may contain variables. `Host`, `Content-Length`, `Transfer-Encoding` and `Connection` are ignored |
| Target | Private and internal addresses are refused, even if an ordinary domain name points to them |
| Redirects | Are not followed. A 3xx response counts as failed |
| Timeout | 15 seconds |

<Callout type="warn" title="No signature">
Unlike **Send webhook**, Tillor does not sign this request. If you want to check that a request comes from your automation, put a secret in a header and check it on your side. Headers are stored encrypted, so a key or token in them is safe.
</Callout>

A response with a 2xx status continues through **Succeeded**, any other status through **Failed**. If the server cannot be reached, or exceeds the timeout, the run stops with the status **Failed**.

## API request to the Tillor API [#api-verzoek-naar-de-tillor-api]

With **Send to** set to **Tillor API**, the automation calls the API of its own organisation. You only give a path, for example `/tasks`, and Tillor places it after `/api/orgs/{orgId}`. Your API reference is at [OpenAPI](https://tillor.eu/api/openapi.json).

- **Identity**: the request is executed as the organisation's Workflow user. That user has all permissions within that organisation and nowhere else. Changes are therefore recorded under the name **Workflow**
- **No key needed**: Tillor makes the call itself, without an API key and without going over the internet
- **Path**: must start with a single `/`. `//`, `..` and `\` are not allowed. A query string is allowed, for example `/tasks?terrainId=…&limit=1`. Variables in the path are filled in encoded
- **Blocked**: the paths `/automations` and `/automation-runs` are refused, also with a query string, capital letters, a trailing `/` or percent-encoding. An automation cannot manage automations
- **Body**: JSON, for `POST`, `PUT` and `PATCH`. For `GET` and `DELETE` it is not sent
- **Picker**: in the editor there is **Pick an API endpoint** with the operations from the OpenAPI specification. Internal operations are not listed. If you pick one, Tillor fills in the method, path and an example body
- **Failure**: a 2xx response continues through **Succeeded**. An error status, including a 404 for a path that does not exist, goes through **Failed**

### The response in later steps [#het-antwoord-in-latere-stappen]

After the request these variables are available:

| Variable | Content |
|---|---|
| `{response.status}` | The HTTP status code |
| `{response.body}` | The first 4000 characters of the response as text |
| `{response.data}` | The response as JSON. `null` if it is not JSON, or if it is longer than 100,000 characters. You address lists with an index, for example `{response.data.items.0.id}` |

A second API request in the same flow replaces `response`. The variables work as described under [Variables and templates](/automatiseringen/variabelen).

## The structure of a flow [#de-opbouw-van-een-flow]

You can also create and change automations through the API. The operations are in [OpenAPI](https://tillor.eu/api/openapi.json) under the tag `automations`. Reading requires the permission `automations:read`, creating and changing `automations:write` (or all permissions). The Workflow user itself can never call them. It may be easier to build a flow in the editor and read it as an example.

A new automation is always disabled. Enabling it through `enabled` does not work as long as the flow has open problems, and an enabled flow cannot be saved with problems.

The `definition` consists of steps (`nodes`), lines (`edges`) and optionally notes (`notes`). Maximum 100 steps, 200 lines and 50 notes.

```json
{
  "nodes": [
    {
      "id": "trigger",
      "type": "trigger",
      "label": "",
      "position": { "x": 0, "y": 0 },
      "config": { "source": "event", "eventKey": "occupation:ended" }
    },
    {
      "id": "task",
      "type": "taskCreate",
      "label": "",
      "position": { "x": 0, "y": 190 },
      "config": { "title": "Controleer {occupation.terrain.name}", "priority": "HIGH" }
    }
  ],
  "edges": [
    { "id": "trigger:out:task", "source": "trigger", "target": "task", "sourceHandle": "out" }
  ],
  "notes": [
    {
      "id": "note_1",
      "text": "Maakt na elk vertrek een controletaak.",
      "position": { "x": 340, "y": 0 },
      "width": 240,
      "height": 140
    }
  ]
}
```

A note (`notes`) is an explanation on the canvas. It is never executed and has no lines. `text` is at most 2000 characters, `width` and `height` are in pixels.

A line has a `sourceHandle`: the exit of the step it comes from.

| Step (`type`) | Exits (`sourceHandle`) |
|---|---|
| `trigger`, `delay`, `waitUntilOpen`, `waitUntilClosed`, `taskCreate`, `taskSetStatus`, `taskSetPriority`, `taskUpdate`, `invoiceReminderSend`, `invoiceSend`, `invoicePrint`, `occupationExtendInvoice`, `staffNotify`, `commentCreate`, `inboxReply`, `inboxTag`, `customerUpdate`, `accessMethodCreate`, `accessMethodUpdate`, `accessMethodSendQr`, `accessPointControl`, `meterSwitch`, `nfcTagUpdate`, `deviceCommand`, `deviceDisplay`, `deviceSlideshow`, `controllerRelay`, `controllerCommand` | `out` |
| `customerMessageSend`, `reservationSetStatus`, `invoiceBook`, `paymentLinkCreate`, `mandateRequest`, `mandateCollect`, `consumptionInvoice` | `out`, `skipped` |
| `condition` | `yes`, `no` |
| `switch` | The `id` of each branch, plus `default` |
| `openingHours` | `open`, `closed` |
| `throttle` | `pass`, `blocked` |
| `taskFind`, `documentFind`, `recordLookup` | `found`, `notFound` |
| `forEach` | `each`, `done` |
| `waitUntil` | `met`, `timeout` |
| `waitForEvent` | `received`, `timeout` |
| `approval` | `approved`, `rejected`, `timeout` |
| `webhookSend`, `httpRequest` | `success`, `failed` |

Every action except `webhookSend` and `httpRequest` gets an extra exit `error` as soon as `continueOnError` in the `config` is set to `true`. Without that setting a failed action stops the run. With that setting the flow continues through `error`, with `{error.message}` and `{error.step}` as variables for the steps after it. The exit `skipped` is used when a step had nothing to do, and `out` is then the ordinary exit.

For `forEach`, the exit `each` starts a separate run per item for the steps after it, and the exit `done` is the ordinary continuation of the flow itself.

An exit may lead to several steps. The run itself continues with the first line and starts a separate run for every other line with the same data, which runs in parallel (like the exit `each` of `forEach`). Lines that form a loop are refused in the editor. A flow has exactly one `trigger`.

### Settings per step [#instellingen-per-stap]

The fields under `config` are the fields from the editor. Text fields accept variables between curly braces.

| Step | Fields in `config` |
|---|---|
| `trigger` | `source` (`event`, `webhook`, `invoiceOverdue`, `dateReached`, `daily` or `cron`), `webhookVersion` (for `webhook`: text, increase it to replace the address), `eventKey`, `date` (for `dateReached`: a path `record.field` to a `DateTime` column of a model that an event sends in full, such as `reservation.checkIn` or `contact.birthday`, or to a declared date key in a JSON column, such as `document.userMetadata.insuranceExpiryDate`; old names such as `reservationCheckIn` keep working), `dateOffset` (`{ "amount", "unit" }`), `dateDirection` (`before` or `after`), `dateTime` (`exact`: the hour in the date, or `fixed`: the calendar day of the date in the organisation's time zone, at `dateHour` and `dateMinute`, text such as `"9"` and `"0"`; the offset counts on the clock, so across summer and winter time), `repeatYearly` (boolean: only day and month count, every year), `hour` and `minute` (text, for example `"8"` and `"0"`, minute 0 to 59 inclusive), `cron` (five fields; the weekday may be `1#2` or `1L`, a sixth field `W2:2026-10-05` repeats every two weeks), `conditions`, `oncePerRecord` (boolean) |
| `condition` | `conditions` |
| `switch` | `field` (a variable path without braces), `cases`: a list of `{ "id", "key", "value" }` with `key` as the name of the branch and `value` as the value the field must equal. Maximum 8 branches |
| `delay` | `mode` (`duration` or `untilDate`), `duration` and `offset` as `{ "amount", "unit" }` where `unit` is `seconds`, `minutes`, `hours`, `days` or `weeks`, `dateField` (variable path), `direction` (`before` or `after`) |
| `taskCreate` | `title`, `description`, `assigneeIds`, `labelIds`, `assignActor`, `priority` (`LOW`, `MEDIUM`, `HIGH` or `URGENT`), `viewId`, `laneId`, `subtasks` (one per line), `dueIn` (`{ "amount", "unit" }`), `linkRecords` |
| `taskSetStatus` | `taskId`, `status` (`PENDING`, `IN_PROGRESS`, `WAITING` or `COMPLETED`) |
| `taskFind` | `title` (exact title), `linkedToRecords`, `onlyOpen`, `onlyTopLevel` (booleans) |
| `documentFind` | `customerId` (template), `documentType` (`INSURANCE_POLICY`, `INSURANCE_PAYMENT_PROOF`, `IDENTITY_CARD`, `SEPA_MANDATE`, `OTHER` or empty), `onlyActive`, `onlyValid` (booleans). Result under `foundDocument` |
| `documentUpdate` | `documentId` (template), `documentType` (empty keeps the type), `status` (`ACTIVE`, `ARCHIVED` or empty) |
| `taskSetPriority` | `taskId`, `mode` (`raise`, `lower` or `set`), `priority` (for `set`), `maxPriority` (for `raise`) |
| `taskUpdate` | `taskId`, `title`, `assigneeIds`, `assignActor`, `assigneeMode` (`add` or `replace`), `labelIds`, `dueIn` (`{ "amount", "unit" }` where `unit` is `minutes`, `hours`, `days` or `weeks`) |
| `invoiceReminderSend`, `invoiceSend`, `invoiceBook` | `invoiceId` |
| `invoicePrint` | `invoiceId`, `printer` (`a4`, `pos` or `tablet`) |
| `paymentLinkCreate` | `invoiceId`, `method` (`any`, `BANCONTACT`, `IDEAL`, `CREDITCARD` or `PAYCONIQ`) |
| `mandateRequest` | `customerId`, `mode` (`request` or `reminder`) |
| `mandateCollect` | `invoiceId`, `delayDays` (text, default `"0"`, at most 7) |
| `consumptionInvoice` | `customerId`, `sendEmail`, `sendSms` |
| `occupationExtendInvoice` | `occupationId`, `includeConsumption` |
| `customerMessageSend` | `customerId`, `subject`, `body`, `sendEmail`, `sendSms`, `sendWhatsApp` |
| `staffNotify` | `userIds`, `notifyActor`, `title`, `body`, `sendPush`, `sendEmail` |
| `commentCreate` | `content`, `target` (`event` or `task`), `taskId` (for `task`) |
| `inboxReply` | `threadId`, `body`, `keepAssistant` |
| `inboxTag` | `threadId`, `tagIds`, `archive` |
| `customerUpdate` | `customerId`, `status` (`keep`, `DEFAULT`, `PREFERRED`, `VIP`, `WARNING` or `BLACKLISTED`), `notes` |
| `reservationSetStatus` | `reservationId`, `action` (`checkIn`, `checkOut` or `cancel`) |
| `accessMethodCreate` | `customerId`, `type` (`QR_CODE`, `LPR`, `PIN_CODE` or `NFC`), `value`, `periodFrom`, `periodTo` (variables with a date, empty is no limit) |
| `accessMethodUpdate` | `scope` (`one` or `customer`), `accessMethodId` (for `one`), `customerId` (for `customer`), `status` (`keep`, `ACTIVE`, `SOFT_BLOCKED`, `BLOCKED` or `INACTIVE`), `periodTo` |
| `accessMethodSendQr` | `accessMethodId`, `sendEmail`, `sendSms`, `sendWhatsApp`, `print` (`none`, `label` or `thermal`) |
| `accessPointControl` | `accessPointId`, `action` (`open` or `close`) |
| `meterSwitch` | `target` (`terrain` or `meter`), `terrainId` (for `terrain`), `meterId` (for `meter`), `state` (`on` or `off`) |
| `nfcTagUpdate` | `customerId`, `action` (`block`, `unblock`, `topUp` or `lowBalance`), `amount` (for `topUp`, in euros per tag) |
| `deviceCommand` | `deviceId`, `command` (`wake`, `sleep`, `reload`, `identify`, `testSound` or `playSound`), `url` (for `playSound`: the path of an uploaded sound, as the editor fills it in, or an https link to an mp3, wav or m4a file) |
| `deviceDisplay` | `kind` (`pdf` or `image`), `url` (https link). Appears on every tablet that is set up as a display, such as an invoice PDF |
| `controllerRelay` | `target` (`controller` or `event`: the controller of the event `controller:input:changed` that started the flow), `controllerId` (for `controller`), `relay` (text `"1"` to `"6"`), `action` (`pulse`, `on` or `off`), `durationSeconds` (for `pulse`, text, 0.001 to 3600 with decimals such as `"0.5"`; the relay drops out again by itself) |
| `controllerCommand` | `target` and `controllerId` as for `controllerRelay`, `command` (`reboot`, `rebootExtension`, `otaUpdate`, `forceOtaUpdate`, `extensionOtaUpdate` or `refreshSettings`) |
| `deviceSlideshow` | `scope` (`displays` or `device`), `mode` (`screensaver` or `background`), `source` (`feed` or `urls`). For `feed`: `itemsPath`, `imageField`, optional filter and sort fields |
| `openingHours`, `waitUntilOpen`, `waitUntilClosed` | No fields |
| `throttle` | `window` (`{ "amount", "unit" }` where `unit` is `minutes`, `hours`, `days` or `weeks`), `key` (empty is per record that started the flow) |
| `recordLookup` | `model` (`Customer`, `Reservation`, `Occupation`, `Invoice`, `Payment`, `Terrain`, `Task`, `Document`, `AccessMethod`, `NfcTag`, `Meter`, `InboxThread` or `InboxMessage`), `recordId`. The result is under `found` plus the model, such as `foundCustomer` |
| `forEach` | `source` (`customerAccessMethods`, `customerNfcTags`, `customerOpenInvoices`, `customerUpcomingReservations`, `customerOccupations`, `customerDocuments` (only `ACTIVE`) or `terrainMeters`), `parentId` (ID of the customer or the terrain). At most 100 items, the item is under `item` |
| `waitUntil` | `conditions`, `interval` and `timeout` (`{ "amount", "unit" }` where `unit` is `minutes`, `hours`, `days` or `weeks`; the interval is at least 5 minutes) |
| `waitForEvent` | `eventKey`, `sameRecord` (boolean), `timeout` (`{ "amount", "unit" }`) |
| `approval` | `title`, `description`, `assigneeIds`, `timeout` (`{ "amount", "unit" }`). The task is under `approvalTask.id` |
| Every action except `webhookSend` and `httpRequest` | `continueOnError` (boolean) |
| `webhookSend` | `webhookId`, `event`, `payload` (JSON as text) |
| `httpRequest` | `target` (`tillor` or `custom`), `method`, `path` (for `tillor`), `url` (for `custom`), `headers` (list of `{ "id", "key", "value" }`), `body` (JSON as text) |

`conditions` has the form `{ "match": "all" or "any", "rules": [...] }`. Each rule is `{ "id", "field", "operator", "value", "values" }`. `operator` is `is`, `isNot`, `contains`, `greaterThan`, `lessThan`, `isOneOf`, `isEmpty` or `isNotEmpty`. You only use `values` with `isOneOf`. An empty list of rules lets everything through.

## Start an automation with a webhook [#een-automatisering-starten-met-een-webhook]

An automation with the trigger `webhook` starts on a `POST` to its own address:

```bash
curl -X POST "https://tillor.eu/api/orgs/org_abc123/automation-hooks/aut_xxx/<token>?bron=website" \
  -H "Content-Type: application/json" \
  -d '{"email":"jan@voorbeeld.nl","aankomst":"2026-07-14"}'
```

- The full address is in the editor at the trigger, or via `GET /automations/{id}/webhook-url` (with `automations:read`). The token is the secret; a header for authentication is not needed
- The JSON body becomes the variable `body`, the query string `query`, and the time `receivedAt`
- The answer is `200` with `{ "accepted": true }` as soon as the run has started. A wrong, replaced or disabled address gives `404`, a body above 100 KB gives `400`
- Many calls shortly after each other are not refused: every valid call starts a run. Use **Ignore repeats** at the trigger if the same call can arrive twice, see [Ignore repeats](/automatiseringen/triggers#herhalingen-negeren)

An automation cannot call its own webhook through an **API request** to the Tillor API.

## Choose a decision through the API [#een-beslissing-kiezen-via-de-api]

The task of an **Ask for a decision** step has one action per option you set in the step. Fetch the task to see the `actions` with their `id`, and choose one with `POST /tasks/{id}/actions/{actionId}/choose`. If the option asks for a note, send it along as `{ "note": "..." }`. The choice is final: it completes the task and continues the automation along the exit of that option. Assigned colleagues (also through a group) and administrators may choose. See the [OpenAPI](https://tillor.eu/api/openapi.json) for the details.

## Read more [#meer-lezen]

- [Webhooks](/ontwikkelaars/webhooks) for signature, retries and the list of events
- [HTTP API](/ontwikkelaars/http) for authentication and the organisation context
- [Variables and templates](/automatiseringen/variabelen) for the user guide


# Event-index (/en-GB/ontwikkelaars/events)

{/* Gegenereerd door bun run --cwd apps/next generate:registry uit de realtime.ts-bestanden. Niet met de hand aanpassen. */}

Deze pagina wordt automatisch opgebouwd uit de code: elk event dat Tillor via [SSE](/ontwikkelaars/sse) of [webhooks](/ontwikkelaars/webhooks) verstuurt, staat hier. In de payload hieronder zie je alleen `event` en `data`; `timestamp`, `traceId` en de andere velden van de [envelop](/ontwikkelaars/webhooks#webhook-payload) komen er altijd bij.

De voorbeeldwaarden zijn verzonnen. De velden en hun types komen rechtstreeks uit het datamodel; een event kan extra relaties meesturen die hier niet staan.

Je ontvangt een event alleen als je organisatielid één van de genoemde permissies heeft. Events met "geen webhook" komen te vaak voor om als webhook te versturen; je kunt ze alleen via SSE volgen.

## Overzicht [#overzicht]

| Event | Beschrijving | Permissie | Levering |
|-------|--------------|-----------|----------|
| `*` | Alle events | volledige toegang (`*`) | SSE + webhook |
| [`accessLogEntry:coupled`](#accesslogentry-coupled) | Toegangslogregel gekoppeld | `access-control:read` | SSE + webhook |
| [`accessLogEntry:processed`](#accesslogentry-processed) | Toegangslogregel verwerkt | `access-control:read` | SSE + webhook |
| [`accessMethod:created`](#accessmethod-created) | Toegangsmethode aangemaakt | `access-control:read` | SSE + webhook |
| [`accessMethod:deleted`](#accessmethod-deleted) | Toegangsmethode verwijderd | `access-control:read` | SSE + webhook |
| [`accessMethod:updated`](#accessmethod-updated) | Toegangsmethode gewijzigd | `access-control:read` | SSE + webhook |
| [`accessMethodOperation:created`](#accessmethodoperation-created) | Bewerking op toegangsmethode gestart | `access-control:read` | SSE + webhook |
| [`accessMethodOperation:updated`](#accessmethodoperation-updated) | Bewerking op toegangsmethode gewijzigd | `access-control:read` | SSE + webhook |
| [`accessPoint:created`](#accesspoint-created) | Toegangspunt aangemaakt | `access-control:read` | SSE + webhook |
| [`accessPoint:deleted`](#accesspoint-deleted) | Toegangspunt verwijderd | `access-control:read` | SSE + webhook |
| [`accessPoint:openTooLong`](#accesspoint-opentoolong) | Toegangspunt te lang open | `access-control:access-point-open:alert` | SSE + webhook |
| [`accessPoint:physicalStateChanged`](#accesspoint-physicalstatechanged) |  | `access-control:read` | SSE, geen webhook |
| [`accessPoint:updated`](#accesspoint-updated) | Toegangspunt gewijzigd | `access-control:read` | SSE + webhook |
| [`bankAccountTransaction:imported`](#bankaccounttransaction-imported) | Banktransactie geïmporteerd | `bank-transactions:read` of `bank-transactions:sync` | SSE + webhook |
| [`call:created`](#call-created) | Telefoongesprek gestart | `calls:read` | SSE + webhook |
| [`call:updated`](#call-updated) | Telefoongesprek gewijzigd | `calls:read` | SSE + webhook |
| [`comment:created`](#comment-created) | Opmerking toegevoegd | `comments:read` | SSE + webhook |
| [`comment:deleted`](#comment-deleted) | Opmerking verwijderd | `comments:read` | SSE + webhook |
| [`comment:mentioned`](#comment-mentioned) | Iemand genoemd in een opmerking | `comments:read` | SSE + webhook |
| [`comment:pinned`](#comment-pinned) | Opmerking vastgezet | `comments:read` | SSE + webhook |
| [`comment:resolved`](#comment-resolved) | Opmerking opgelost | `comments:read` | SSE + webhook |
| [`comment:unresolved`](#comment-unresolved) | Opmerking heropend | `comments:read` | SSE + webhook |
| [`comment:updated`](#comment-updated) | Opmerking bewerkt | `comments:read` | SSE + webhook |
| [`controller:adoption:approved`](#controller-adoption-approved) | Adoptie van besturingseenheid goedgekeurd | `controllers:read` | SSE + webhook |
| [`controller:adoption:rejected`](#controller-adoption-rejected) | Adoptie van besturingseenheid afgewezen | `controllers:read` | SSE + webhook |
| [`controller:adoption:requested`](#controller-adoption-requested) | Besturingseenheid vraagt om adoptie | `controllers:read` | SSE + webhook |
| [`controller:created`](#controller-created) | Besturingseenheid aangemaakt | `controllers:read` | SSE + webhook |
| [`controller:deleted`](#controller-deleted) | Besturingseenheid verwijderd | `controllers:read` | SSE + webhook |
| [`controller:input:changed`](#controller-input-changed) | Ingang van controller veranderd | `controllers:read` | SSE + webhook |
| [`controller:io:changed`](#controller-io-changed) |  | `controllers:read` | SSE (`?channel=controller-io`), geen webhook |
| [`controller:logs:submitted`](#controller-logs-submitted) |  | `controllers:logs` | SSE (`?channel=controller-logs`), geen webhook |
| [`controller:updated`](#controller-updated) | Besturingseenheid gewijzigd | `controllers:read` | SSE + webhook |
| [`customEnum:created`](#customenum-created) |  | elk lid | SSE, geen webhook |
| [`customEnum:deleted`](#customenum-deleted) |  | elk lid | SSE, geen webhook |
| [`customEnum:updated`](#customenum-updated) |  | elk lid | SSE, geen webhook |
| [`customer:contact:created`](#customer-contact-created) | Contactpersoon toegevoegd aan een klant | `customers:read` | SSE + webhook |
| [`customer:contact:deleted`](#customer-contact-deleted) | Contactpersoon verwijderd bij een klant | `customers:read` | SSE + webhook |
| [`customer:contact:updated`](#customer-contact-updated) | Contactpersoon van klant gewijzigd | `customers:read` | SSE + webhook |
| [`customer:created`](#customer-created) | Klant aangemaakt | `customers:read` | SSE + webhook |
| [`customer:deleted`](#customer-deleted) | Klant verwijderd | `customers:read` | SSE + webhook |
| [`customer:updated`](#customer-updated) | Klant gewijzigd | `customers:read` | SSE + webhook |
| [`customFieldDefinition:created`](#customfielddefinition-created) |  | elk lid | SSE, geen webhook |
| [`customFieldDefinition:deleted`](#customfielddefinition-deleted) |  | elk lid | SSE, geen webhook |
| [`customFieldDefinition:updated`](#customfielddefinition-updated) |  | elk lid | SSE, geen webhook |
| [`document:created`](#document-created) | Document ontvangen | `documents:read` | SSE + webhook |
| [`document:deleted`](#document-deleted) | Document verwijderd | `documents:read` | SSE + webhook |
| [`document:updated`](#document-updated) | Document gewijzigd | `documents:read` | SSE + webhook |
| [`event-log:created`](#event-log-created) | Gebeurtenis gelogd | `audit-logs:read` | SSE + webhook |
| [`identityDocumentScan:completed`](#identitydocumentscan-completed) | ID-scan voltooid | `identity-document-scans:read` | SSE + webhook |
| [`identityDocumentScan:deleted`](#identitydocumentscan-deleted) | ID-scan verwijderd | `identity-document-scans:read` | SSE + webhook |
| [`identityDocumentScan:linked`](#identitydocumentscan-linked) | ID-scan gekoppeld aan een klant | `identity-document-scans:read` | SSE + webhook |
| [`identityDocumentScan:pendingQueueChanged`](#identitydocumentscan-pendingqueuechanged) | Wachtrij voor ID-scans gewijzigd | `identity-document-scans:read` | SSE + webhook |
| [`identityDocumentScan:unlinked`](#identitydocumentscan-unlinked) | ID-scan ontkoppeld | `identity-document-scans:read` | SSE + webhook |
| [`img:clear-tablet`](#img-clear-tablet) | Afbeelding gewist van een tablet | `native-devices:read` | SSE + webhook |
| [`img:to-tablet`](#img-to-tablet) | Afbeelding naar een tablet gestuurd | `native-devices:read` | SSE + webhook |
| [`inbox:message-created`](#inbox-message-created) | Bericht ontvangen in de inbox | `inbox:read` | SSE + webhook |
| [`inbox:participant-reaction`](#inbox-participant-reaction) | Reactie op een inboxbericht | `inbox:read` | SSE + webhook |
| [`inbox:thread-updated`](#inbox-thread-updated) | Inboxgesprek gewijzigd | `inbox:read` | SSE + webhook |
| [`inbox:typing-changed`](#inbox-typing-changed) |  | `inbox:read` | SSE, geen webhook |
| [`inbox:urgent-handoff`](#inbox-urgent-handoff) | Dringende overdracht door de assistent | `inbox:read` | SSE + webhook |
| [`integration-alarm:created`](#integration-alarm-created) | Meteralarm afgegaan | `meters:read` | SSE + webhook |
| [`integration-alarm:resolved`](#integration-alarm-resolved) | Meteralarm opgelost | `meters:read` | SSE + webhook |
| [`invoice:created`](#invoice-created) | Factuur aangemaakt | `invoices:read` | SSE + webhook |
| [`invoice:deleted`](#invoice-deleted) | Factuur verwijderd | `invoices:read` | SSE + webhook |
| [`invoice:moved-to-customer`](#invoice-moved-to-customer) | Factuur naar een andere klant verplaatst | `invoices:read` | SSE + webhook |
| [`invoice:paid`](#invoice-paid) | Factuur betaald | `invoices:read` | SSE + webhook |
| [`invoice:updated`](#invoice-updated) | Factuur gewijzigd | `invoices:read` | SSE + webhook |
| [`ledgerOpeningBalance:created`](#ledgeropeningbalance-created) | Beginsaldo toegevoegd | `invoices:read` | SSE + webhook |
| [`ledgerOpeningBalance:deleted`](#ledgeropeningbalance-deleted) | Beginsaldo verwijderd | `invoices:read` | SSE + webhook |
| [`ledgerOpeningBalance:updated`](#ledgeropeningbalance-updated) | Beginsaldo gewijzigd | `invoices:read` | SSE + webhook |
| [`mandate-agreement:activated`](#mandate-agreement-activated) | Mandaat actief | `payments:read` | SSE + webhook |
| [`mandate-agreement:expired`](#mandate-agreement-expired) | Mandaataanvraag verlopen | `payments:read` | SSE + webhook |
| [`mandate-agreement:failed`](#mandate-agreement-failed) | Mandaat geweigerd | `payments:read` | SSE + webhook |
| [`mandate-agreement:signed`](#mandate-agreement-signed) | Mandaat ondertekend | `payments:read` | SSE + webhook |
| [`mandate-agreement:updated`](#mandate-agreement-updated) | Mandaataanvraag gewijzigd | `payments:read` | SSE + webhook |
| [`mandate:created`](#mandate-created) | Mandaat aangemaakt | `payments:read` | SSE + webhook |
| [`mandate:deleted`](#mandate-deleted) | Mandaat verwijderd | `payments:read` | SSE + webhook |
| [`mandate:updated`](#mandate-updated) | Mandaat gewijzigd | `payments:read` | SSE + webhook |
| [`meter:created`](#meter-created) | Meter aangemaakt | `meters:read` | SSE + webhook |
| [`meter:updated`](#meter-updated) | Meter gewijzigd | `meters:read` | SSE + webhook |
| [`meterAnomaly:detected`](#meteranomaly-detected) | Meterafwijking vastgesteld | `meters:read` | SSE + webhook |
| [`meterAnomaly:resolved`](#meteranomaly-resolved) | Meterafwijking opgelost | `meters:read` | SSE + webhook |
| [`meterConsumptionBatch:created`](#meterconsumptionbatch-created) | Verbruiksperiode gestart | `meters:read` | SSE + webhook |
| [`meterConsumptionBatch:updated`](#meterconsumptionbatch-updated) | Verbruiksperiode gewijzigd | `meters:read` | SSE + webhook |
| [`meterReading:created`](#meterreading-created) | Meterstand ingevoerd | `meters:read` | SSE + webhook |
| [`meterReading:deleted`](#meterreading-deleted) | Meterstand verwijderd | `meters:read` | SSE + webhook |
| [`meterReading:synced`](#meterreading-synced) | Meterstand gesynchroniseerd | `meters:read` | SSE + webhook |
| [`meterReading:updated`](#meterreading-updated) | Meterstand gewijzigd | `meters:read` | SSE + webhook |
| [`nativeDevice:command`](#nativedevice-command) |  | `native-devices:read` | SSE, geen webhook |
| [`nativeDevice:config`](#nativedevice-config) |  | `native-devices:read` | SSE, geen webhook |
| [`nativeDevice:deleted`](#nativedevice-deleted) | Tablet of kiosk verwijderd | `native-devices:read` | SSE + webhook |
| [`nfc-tag-transaction:changed`](#nfc-tag-transaction-changed) | NFC-tagtransactie gewijzigd | `nfc-tag-transactions:read` | SSE + webhook |
| [`nfc-tag:blocked`](#nfc-tag-blocked) | NFC-tag geblokkeerd | `nfc-tags:read` | SSE + webhook |
| [`nfc-tag:presented`](#nfc-tag-presented) | NFC-tag aangeboden | `nfc-tags:read` | SSE + webhook |
| [`nfc-tag:unblocked`](#nfc-tag-unblocked) | NFC-tag gedeblokkeerd | `nfc-tags:read` | SSE + webhook |
| [`nfc-tag:updated`](#nfc-tag-updated) | NFC-tag gewijzigd | `nfc-tags:read` | SSE + webhook |
| [`notification-delivery:deleted`](#notification-delivery-deleted) | Melding verwijderd | `notifications:deliveries:read` | SSE + webhook |
| [`notification-delivery:updated`](#notification-delivery-updated) | Status van melding gewijzigd | `notifications:deliveries:read` | SSE + webhook |
| [`notificationInbox:created`](#notificationinbox-created) |  | elk lid | SSE, geen webhook |
| [`notificationInbox:read`](#notificationinbox-read) |  | elk lid | SSE, geen webhook |
| [`occupation:ended`](#occupation-ended) | Bezetting beëindigd | `terrains:read` | SSE + webhook |
| [`organizationSettings:updated`](#organizationsettings-updated) | Instellingen gewijzigd | `organization:settings:read` of `organization:settings:write` | SSE + webhook |
| [`payment-group:assigned-to-invoice`](#payment-group-assigned-to-invoice) | Betalingsgroep gekoppeld aan een factuur | `payments:read` | SSE + webhook |
| [`payment-group:created`](#payment-group-created) | Betalingsgroep aangemaakt | `payments:read` | SSE + webhook |
| [`payment-group:deleted`](#payment-group-deleted) | Betalingsgroep verwijderd | `payments:read` | SSE + webhook |
| [`payment-group:payments-added`](#payment-group-payments-added) | Betalingen toegevoegd aan een groep | `payments:read` | SSE + webhook |
| [`payment-group:payments-removed`](#payment-group-payments-removed) | Betalingen verwijderd uit een groep | `payments:read` | SSE + webhook |
| [`payment-group:unassigned-from-invoice`](#payment-group-unassigned-from-invoice) | Betalingsgroep ontkoppeld van een factuur | `payments:read` | SSE + webhook |
| [`payment-group:updated`](#payment-group-updated) | Betalingsgroep gewijzigd | `payments:read` | SSE + webhook |
| [`payment-report:created`](#payment-report-created) | Betalingsrapport aangemaakt | `payment-reports:read` | SSE + webhook |
| [`payment-report:updated`](#payment-report-updated) | Betalingsrapport gewijzigd | `payment-reports:read` | SSE + webhook |
| [`payment:created`](#payment-created) | Betaling aangemaakt | `payments:read` | SSE + webhook |
| [`payment:deleted`](#payment-deleted) | Betaling verwijderd | `payments:read` | SSE + webhook |
| [`payment:updated`](#payment-updated) | Betaling gewijzigd | `payments:read` | SSE + webhook |
| [`pdf:clear-tablet`](#pdf-clear-tablet) | Pdf gewist van een tablet | `native-devices:read` | SSE + webhook |
| [`pdf:to-tablet`](#pdf-to-tablet) | Pdf naar een tablet gestuurd | `native-devices:read` | SSE + webhook |
| [`print-queue-job:updated`](#print-queue-job-updated) | Printopdracht gewijzigd | `printing:read` | SSE + webhook |
| [`product:created`](#product-created) | Product aangemaakt | `products:read` | SSE + webhook |
| [`product:deleted`](#product-deleted) | Product verwijderd | `products:read` | SSE + webhook |
| [`product:updated`](#product-updated) | Product gewijzigd | `products:read` | SSE + webhook |
| [`productPriceChange:applied`](#productpricechange-applied) | Geplande productprijs toegepast | `products:read` | SSE + webhook |
| [`productPriceChange:created`](#productpricechange-created) | Productprijs gepland | `products:read` | SSE + webhook |
| [`productPriceChange:deleted`](#productpricechange-deleted) | Geplande productprijs verwijderd | `products:read` | SSE + webhook |
| [`reservation:created`](#reservation-created) | Reservering aangemaakt | `reservations:read` | SSE + webhook |
| [`reservation:updated`](#reservation-updated) | Reservering gewijzigd | `reservations:read` | SSE + webhook |
| [`sign:clear-tablet`](#sign-clear-tablet) | Ondertekening gewist van een tablet | `native-devices:read` | SSE + webhook |
| [`sign:to-tablet`](#sign-to-tablet) | Ondertekening naar een tablet gestuurd | `native-devices:read` | SSE + webhook |
| [`signatureRequest:completed`](#signaturerequest-completed) | Ondertekenverzoek afgerond | `signature-requests:read` | SSE + webhook |
| [`signatureRequest:deleted`](#signaturerequest-deleted) | Ondertekenverzoek verwijderd | `signature-requests:read` | SSE + webhook |
| [`signatureRequest:updated`](#signaturerequest-updated) | Ondertekenverzoek gewijzigd | `signature-requests:read` | SSE + webhook |
| [`task-time-tracker:changed`](#task-time-tracker-changed) |  | `tasks:read` | SSE, geen webhook |
| [`task-view:created`](#task-view-created) | Takenweergave aangemaakt | `tasks:read` | SSE + webhook |
| [`task-view:deleted`](#task-view-deleted) | Takenweergave verwijderd | `tasks:read` | SSE + webhook |
| [`task-view:membership-changed`](#task-view-membership-changed) | Taken in een weergave gewijzigd | `tasks:read` | SSE + webhook |
| [`task-view:updated`](#task-view-updated) | Takenweergave gewijzigd | `tasks:read` | SSE + webhook |
| [`task:action-chosen`](#task-action-chosen) | Taakactie gekozen | `tasks:read` | SSE + webhook |
| [`task:assigned`](#task-assigned) | Taak toegewezen | `tasks:read` | SSE + webhook |
| [`task:created`](#task-created) | Taak aangemaakt | `tasks:read` | SSE + webhook |
| [`task:deleted`](#task-deleted) | Taak verwijderd | `tasks:read` | SSE + webhook |
| [`task:status-changed`](#task-status-changed) | Taakstatus gewijzigd | `tasks:read` | SSE + webhook |
| [`task:unassigned`](#task-unassigned) | Taaktoewijzing opgeheven | `tasks:read` | SSE + webhook |
| [`task:updated`](#task-updated) | Taak gewijzigd | `tasks:read` | SSE + webhook |
| [`terrain:updated`](#terrain-updated) | Terrein gewijzigd | `terrains:read` | SSE + webhook |
| [`vehiclePresence:updated`](#vehiclepresence-updated) |  | `access-control:read` | SSE, geen webhook |

## accessLogEntry [#accesslogentry]

### `accessLogEntry:coupled` [#accesslogentry-coupled]

Toegangslogregel gekoppeld.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessLogEntry:coupled",
  "data": {
    "nfcQrEntryId": "cm4k7x2pq0001abcd1234efgh",
    "lprEntryId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `accessLogEntry:processed` [#accesslogentry-processed]

Toegangslogregel verwerkt.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessLogEntry:processed",
  "data": {
    "organizationId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## accessMethod [#accessmethod]

### `accessMethod:created` [#accessmethod-created]

Toegangsmethode aangemaakt.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessMethod:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "type": "NFC",
    "value": "Voorbeeld",
    "status": "BLOCKED",
    "brand": "Voorbeeld",
    "color": "Voorbeeld",
    "model": "Voorbeeld",
    "periodFrom": "2026-01-15T09:30:00.000Z",
    "periodTo": "2026-01-15T09:30:00.000Z",
    "comments": "Voorbeeld",
    "doNotAutoExtend": false,
    "autoConvertToLpr": false,
    "metadata": {},
    "customFields": {},
    "lastSyncedAt": "2026-01-15T09:30:00.000Z",
    "lastAccessLogEntryId": "cm4k7x2pq0001abcd1234efgh",
    "lastAccessLogAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `accessMethod:deleted` [#accessmethod-deleted]

Toegangsmethode verwijderd.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessMethod:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "type": "NFC",
    "value": "Voorbeeld",
    "status": "BLOCKED",
    "brand": "Voorbeeld",
    "color": "Voorbeeld",
    "model": "Voorbeeld",
    "periodFrom": "2026-01-15T09:30:00.000Z",
    "periodTo": "2026-01-15T09:30:00.000Z",
    "comments": "Voorbeeld",
    "doNotAutoExtend": false,
    "autoConvertToLpr": false,
    "metadata": {},
    "customFields": {},
    "lastSyncedAt": "2026-01-15T09:30:00.000Z",
    "lastAccessLogEntryId": "cm4k7x2pq0001abcd1234efgh",
    "lastAccessLogAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `accessMethod:updated` [#accessmethod-updated]

Toegangsmethode gewijzigd.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessMethod:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "type": "NFC",
    "value": "Voorbeeld",
    "status": "BLOCKED",
    "brand": "Voorbeeld",
    "color": "Voorbeeld",
    "model": "Voorbeeld",
    "periodFrom": "2026-01-15T09:30:00.000Z",
    "periodTo": "2026-01-15T09:30:00.000Z",
    "comments": "Voorbeeld",
    "doNotAutoExtend": false,
    "autoConvertToLpr": false,
    "metadata": {},
    "customFields": {},
    "lastSyncedAt": "2026-01-15T09:30:00.000Z",
    "lastAccessLogEntryId": "cm4k7x2pq0001abcd1234efgh",
    "lastAccessLogAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## accessMethodOperation [#accessmethodoperation]

### `accessMethodOperation:created` [#accessmethodoperation-created]

Bewerking op toegangsmethode gestart.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `accessMethodOperation:updated` [#accessmethodoperation-updated]

Bewerking op toegangsmethode gewijzigd.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessMethodOperation:updated",
  "data": {
    "operationId": "cm4k7x2pq0001abcd1234efgh",
    "status": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

## accessPoint [#accesspoint]

### `accessPoint:created` [#accesspoint-created]

Toegangspunt aangemaakt.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessPoint:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "type": "ENTRANCE",
    "actuatorType": "CONNECTOR",
    "openConfig": {},
    "closeConfig": {},
    "dialPinCodes": {},
    "isActive": false,
    "description": "Voorbeeld",
    "physicalState": "OPEN",
    "physicalStateChangedAt": "2026-01-15T09:30:00.000Z",
    "lastLprHeartbeatAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `accessPoint:deleted` [#accesspoint-deleted]

Toegangspunt verwijderd.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessPoint:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "type": "ENTRANCE",
    "actuatorType": "CONNECTOR",
    "openConfig": {},
    "closeConfig": {},
    "dialPinCodes": {},
    "isActive": false,
    "description": "Voorbeeld",
    "physicalState": "OPEN",
    "physicalStateChangedAt": "2026-01-15T09:30:00.000Z",
    "lastLprHeartbeatAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `accessPoint:openTooLong` [#accesspoint-opentoolong]

Toegangspunt te lang open.

- **Permissie:** `access-control:access-point-open:alert`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessPoint:openTooLong",
  "data": {
    "accessPointId": "cm4k7x2pq0001abcd1234efgh",
    "accessPointName": "Voorbeeld",
    "openSince": "2026-01-15T09:30:00.000Z",
    "afterMinutes": 12.5
  }
}
```

</Accordion>
</Accordions>

### `accessPoint:physicalStateChanged` [#accesspoint-physicalstatechanged]

- **Permissie:** `access-control:read`
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessPoint:physicalStateChanged",
  "data": {
    "accessPointId": "cm4k7x2pq0001abcd1234efgh",
    "state": "OPEN",
    "previousState": "OPEN",
    "changedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `accessPoint:updated` [#accesspoint-updated]

Toegangspunt gewijzigd.

- **Permissie:** `access-control:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "accessPoint:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "type": "ENTRANCE",
    "actuatorType": "CONNECTOR",
    "openConfig": {},
    "closeConfig": {},
    "dialPinCodes": {},
    "isActive": false,
    "description": "Voorbeeld",
    "physicalState": "OPEN",
    "physicalStateChangedAt": "2026-01-15T09:30:00.000Z",
    "lastLprHeartbeatAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## bankAccountTransaction [#bankaccounttransaction]

### `bankAccountTransaction:imported` [#bankaccounttransaction-imported]

Banktransactie geïmporteerd.

- **Permissie:** `bank-transactions:read` of `bank-transactions:sync`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "bankAccountTransaction:imported",
  "data": {
    "transactionsProcessed": 12.5,
    "accountsProcessed": 12.5
  }
}
```

</Accordion>
</Accordions>

## call [#call]

### `call:created` [#call-created]

Telefoongesprek gestart.

- **Permissie:** `calls:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "call:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "externalId": "cm4k7x2pq0001abcd1234efgh",
    "to": "Voorbeeld",
    "from": "Voorbeeld",
    "state": "CREATED",
    "direction": "INBOUND",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "contactId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "duration": 1,
    "recordingS3Path": "Voorbeeld",
    "recordingStatus": "PENDING",
    "maybeCallerName": "Voorbeeld",
    "currentTranscriptionId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `call:updated` [#call-updated]

Telefoongesprek gewijzigd.

- **Permissie:** `calls:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "call:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "externalId": "cm4k7x2pq0001abcd1234efgh",
    "to": "Voorbeeld",
    "from": "Voorbeeld",
    "state": "CREATED",
    "direction": "INBOUND",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "contactId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "duration": 1,
    "recordingS3Path": "Voorbeeld",
    "recordingStatus": "PENDING",
    "maybeCallerName": "Voorbeeld",
    "currentTranscriptionId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## comment [#comment]

### `comment:created` [#comment-created]

Opmerking toegevoegd.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:deleted` [#comment-deleted]

Opmerking verwijderd.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:mentioned` [#comment-mentioned]

Iemand genoemd in een opmerking.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:mentioned",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:pinned` [#comment-pinned]

Opmerking vastgezet.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:pinned",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:resolved` [#comment-resolved]

Opmerking opgelost.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:resolved",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:unresolved` [#comment-unresolved]

Opmerking heropend.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:unresolved",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `comment:updated` [#comment-updated]

Opmerking bewerkt.

- **Permissie:** `comments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "comment:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "content": "Voorbeeld",
    "sanitizedContent": "Voorbeeld",
    "pinned": false,
    "inboundEmailId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "resolvedAt": "2026-01-15T09:30:00.000Z",
    "resolvedById": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## controller [#controller]

### `controller:adoption:approved` [#controller-adoption-approved]

Adoptie van besturingseenheid goedgekeurd.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:adoption:approved",
  "data": {
    "adoptionId": "cm4k7x2pq0001abcd1234efgh",
    "controllerId": "cm4k7x2pq0001abcd1234efgh",
    "efuseId": "cm4k7x2pq0001abcd1234efgh",
    "organizationId": "cm4k7x2pq0001abcd1234efgh",
    "takeover": false
  }
}
```

</Accordion>
</Accordions>

### `controller:adoption:rejected` [#controller-adoption-rejected]

Adoptie van besturingseenheid afgewezen.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:adoption:rejected",
  "data": {
    "adoptionId": "cm4k7x2pq0001abcd1234efgh",
    "efuseId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `controller:adoption:requested` [#controller-adoption-requested]

Besturingseenheid vraagt om adoptie.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:adoption:requested",
  "data": {
    "adoptionId": "cm4k7x2pq0001abcd1234efgh",
    "efuseId": "cm4k7x2pq0001abcd1234efgh",
    "requestedFromIp": "Voorbeeld",
    "isNew": false
  }
}
```

</Accordion>
</Accordions>

### `controller:created` [#controller-created]

Besturingseenheid aangemaakt.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "efuseId": "cm4k7x2pq0001abcd1234efgh",
    "publicKeyPem": "Voorbeeld",
    "model": "Voorbeeld",
    "type": "ACCESS",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "lastSeenAt": "2026-01-15T09:30:00.000Z",
    "lastSyncAt": "2026-01-15T09:30:00.000Z",
    "version": "Voorbeeld",
    "metadata": {},
    "commandManifest": {},
    "controllerGroupId": "cm4k7x2pq0001abcd1234efgh",
    "controllerSettingsId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `controller:deleted` [#controller-deleted]

Besturingseenheid verwijderd.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "efuseId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `controller:input:changed` [#controller-input-changed]

Ingang van controller veranderd.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:input:changed",
  "data": {
    "controller": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "efuseId": "cm4k7x2pq0001abcd1234efgh",
      "publicKeyPem": "Voorbeeld",
      "model": "Voorbeeld",
      "type": "ACCESS",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "lastSeenAt": "2026-01-15T09:30:00.000Z",
      "lastSyncAt": "2026-01-15T09:30:00.000Z",
      "version": "Voorbeeld",
      "metadata": {},
      "commandManifest": {},
      "controllerGroupId": "cm4k7x2pq0001abcd1234efgh",
      "controllerSettingsId": "cm4k7x2pq0001abcd1234efgh"
    },
    "input": 12.5,
    "active": false
  }
}
```

</Accordion>
</Accordions>

### `controller:io:changed` [#controller-io-changed]

- **Permissie:** `controllers:read`
- **Levering:** SSE (`?channel=controller-io`), geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:io:changed",
  "data": {
    "controllerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `controller:logs:submitted` [#controller-logs-submitted]

- **Permissie:** `controllers:logs`
- **Levering:** SSE (`?channel=controller-logs`), geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:logs:submitted",
  "data": {
    "controllerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `controller:updated` [#controller-updated]

Besturingseenheid gewijzigd.

- **Permissie:** `controllers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "controller:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "efuseId": "cm4k7x2pq0001abcd1234efgh",
    "publicKeyPem": "Voorbeeld",
    "model": "Voorbeeld",
    "type": "ACCESS",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "lastSeenAt": "2026-01-15T09:30:00.000Z",
    "lastSyncAt": "2026-01-15T09:30:00.000Z",
    "version": "Voorbeeld",
    "metadata": {},
    "commandManifest": {},
    "controllerGroupId": "cm4k7x2pq0001abcd1234efgh",
    "controllerSettingsId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## customEnum [#customenum]

### `customEnum:created` [#customenum-created]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `customEnum:deleted` [#customenum-deleted]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `customEnum:updated` [#customenum-updated]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

## customer [#customer]

### `customer:contact:created` [#customer-contact-created]

Contactpersoon toegevoegd aan een klant.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:contact:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "relation": "SPOUSE",
    "relationOther": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "address": "Voorbeeld",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "comments": "Voorbeeld",
    "isEmergencyContact": false,
    "mentionOnInvoice": false,
    "locale": "nl",
    "country": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `customer:contact:deleted` [#customer-contact-deleted]

Contactpersoon verwijderd bij een klant.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:contact:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "relation": "SPOUSE",
    "relationOther": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "address": "Voorbeeld",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "comments": "Voorbeeld",
    "isEmergencyContact": false,
    "mentionOnInvoice": false,
    "locale": "nl",
    "country": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `customer:contact:updated` [#customer-contact-updated]

Contactpersoon van klant gewijzigd.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:contact:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "relation": "SPOUSE",
    "relationOther": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "address": "Voorbeeld",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "comments": "Voorbeeld",
    "isEmergencyContact": false,
    "mentionOnInvoice": false,
    "locale": "nl",
    "country": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `customer:created` [#customer-created]

Klant aangemaakt.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": 1,
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "address": "Voorbeeld",
    "city": "Voorbeeld",
    "state": "Voorbeeld",
    "zipCode": "Voorbeeld",
    "country": "Voorbeeld",
    "vatNumber": "Voorbeeld",
    "notes": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "customerType": "STANDARD",
    "status": "DEFAULT",
    "metadata": {},
    "customFields": {},
    "locale": "nl",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "consentToCommunications": false,
    "consentToMarketing": false
  }
}
```

</Accordion>
</Accordions>

### `customer:deleted` [#customer-deleted]

Klant verwijderd.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": 1,
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "address": "Voorbeeld",
    "city": "Voorbeeld",
    "state": "Voorbeeld",
    "zipCode": "Voorbeeld",
    "country": "Voorbeeld",
    "vatNumber": "Voorbeeld",
    "notes": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "customerType": "STANDARD",
    "status": "DEFAULT",
    "metadata": {},
    "customFields": {},
    "locale": "nl",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "consentToCommunications": false,
    "consentToMarketing": false
  }
}
```

</Accordion>
</Accordions>

### `customer:updated` [#customer-updated]

Klant gewijzigd.

- **Permissie:** `customers:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "customer:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": 1,
    "firstName": "Voorbeeld",
    "lastName": "Voorbeeld",
    "email": "gast@example.com",
    "phone": "+32470123456",
    "address": "Voorbeeld",
    "city": "Voorbeeld",
    "state": "Voorbeeld",
    "zipCode": "Voorbeeld",
    "country": "Voorbeeld",
    "vatNumber": "Voorbeeld",
    "notes": "Voorbeeld",
    "birthday": "2026-01-15T09:30:00.000Z",
    "birthplace": "Voorbeeld",
    "profession": "Voorbeeld",
    "personalNumber": "Voorbeeld",
    "customerType": "STANDARD",
    "status": "DEFAULT",
    "metadata": {},
    "customFields": {},
    "locale": "nl",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "consentToCommunications": false,
    "consentToMarketing": false
  }
}
```

</Accordion>
</Accordions>

## customFieldDefinition [#customfielddefinition]

### `customFieldDefinition:created` [#customfielddefinition-created]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `customFieldDefinition:deleted` [#customfielddefinition-deleted]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `customFieldDefinition:updated` [#customfielddefinition-updated]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

## document [#document]

### `document:created` [#document-created]

Document ontvangen.

- **Permissie:** `documents:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "document:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "status": "ACTIVE",
    "userMetadata": {},
    "customFields": {},
    "externalId": "cm4k7x2pq0001abcd1234efgh",
    "source": "Voorbeeld",
    "key": "Voorbeeld",
    "previewKey": "Voorbeeld",
    "storageClass": "Voorbeeld",
    "versionId": "cm4k7x2pq0001abcd1234efgh",
    "contentType": "Voorbeeld",
    "size": "Voorbeeld",
    "etag": "Voorbeeld",
    "sha256": "Voorbeeld",
    "filename": "Voorbeeld",
    "extension": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "metadata": {}
  }
}
```

</Accordion>
</Accordions>

### `document:deleted` [#document-deleted]

Document verwijderd.

- **Permissie:** `documents:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "document:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "status": "ACTIVE",
    "userMetadata": {},
    "customFields": {},
    "externalId": "cm4k7x2pq0001abcd1234efgh",
    "source": "Voorbeeld",
    "key": "Voorbeeld",
    "previewKey": "Voorbeeld",
    "storageClass": "Voorbeeld",
    "versionId": "cm4k7x2pq0001abcd1234efgh",
    "contentType": "Voorbeeld",
    "size": "Voorbeeld",
    "etag": "Voorbeeld",
    "sha256": "Voorbeeld",
    "filename": "Voorbeeld",
    "extension": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "metadata": {}
  }
}
```

</Accordion>
</Accordions>

### `document:updated` [#document-updated]

Document gewijzigd.

- **Permissie:** `documents:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "document:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "status": "ACTIVE",
    "userMetadata": {},
    "customFields": {},
    "externalId": "cm4k7x2pq0001abcd1234efgh",
    "source": "Voorbeeld",
    "key": "Voorbeeld",
    "previewKey": "Voorbeeld",
    "storageClass": "Voorbeeld",
    "versionId": "cm4k7x2pq0001abcd1234efgh",
    "contentType": "Voorbeeld",
    "size": "Voorbeeld",
    "etag": "Voorbeeld",
    "sha256": "Voorbeeld",
    "filename": "Voorbeeld",
    "extension": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "metadata": {}
  }
}
```

</Accordion>
</Accordions>

## event-log [#event-log]

### `event-log:created` [#event-log-created]

Gebeurtenis gelogd.

- **Permissie:** `audit-logs:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "event-log:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "type": "INVOICE_CREATED",
    "metadata": {},
    "translationKey": "Voorbeeld",
    "translationData": {},
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "triggeredById": "cm4k7x2pq0001abcd1234efgh",
    "userId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "occupationId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "meterReadingId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "productId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "organizationSettingsId": "cm4k7x2pq0001abcd1234efgh",
    "organizationMembershipId": "cm4k7x2pq0001abcd1234efgh",
    "nativeDeviceId": "cm4k7x2pq0001abcd1234efgh",
    "oauthClientId": "cm4k7x2pq0001abcd1234efgh",
    "oauthConsentId": "cm4k7x2pq0001abcd1234efgh",
    "accessMethodId": "cm4k7x2pq0001abcd1234efgh",
    "contactId": "cm4k7x2pq0001abcd1234efgh",
    "customerInvoicingSettingsId": "cm4k7x2pq0001abcd1234efgh",
    "nfcTagId": "cm4k7x2pq0001abcd1234efgh",
    "identityDocumentScanId": "cm4k7x2pq0001abcd1234efgh",
    "documentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "signatureRequestId": "cm4k7x2pq0001abcd1234efgh",
    "paymentGroupId": "cm4k7x2pq0001abcd1234efgh",
    "controllerId": "cm4k7x2pq0001abcd1234efgh",
    "accessPointId": "cm4k7x2pq0001abcd1234efgh",
    "accessControllerId": "cm4k7x2pq0001abcd1234efgh",
    "organizationId": "cm4k7x2pq0001abcd1234efgh",
    "organizationInvitationId": "cm4k7x2pq0001abcd1234efgh",
    "apiKeyId": "cm4k7x2pq0001abcd1234efgh",
    "integrationInstallationId": "cm4k7x2pq0001abcd1234efgh",
    "dpaAcceptanceId": "cm4k7x2pq0001abcd1234efgh",
    "webhookId": "cm4k7x2pq0001abcd1234efgh",
    "automationId": "cm4k7x2pq0001abcd1234efgh",
    "staffGroupId": "cm4k7x2pq0001abcd1234efgh",
    "terrainTypeId": "cm4k7x2pq0001abcd1234efgh",
    "meterCabinetId": "cm4k7x2pq0001abcd1234efgh",
    "controllerGroupId": "cm4k7x2pq0001abcd1234efgh",
    "customFieldDefinitionId": "cm4k7x2pq0001abcd1234efgh",
    "customEnumId": "cm4k7x2pq0001abcd1234efgh",
    "customerCommunicationSettingsId": "cm4k7x2pq0001abcd1234efgh",
    "taskLabelId": "cm4k7x2pq0001abcd1234efgh",
    "inboxTagId": "cm4k7x2pq0001abcd1234efgh",
    "taskViewId": "cm4k7x2pq0001abcd1234efgh",
    "customerLedgerOpeningBalanceId": "cm4k7x2pq0001abcd1234efgh",
    "auditLogId": "cm4k7x2pq0001abcd1234efgh",
    "actorKind": "USER",
    "actorApiKeyId": "cm4k7x2pq0001abcd1234efgh",
    "actorOauthClientId": "cm4k7x2pq0001abcd1234efgh",
    "actorImpersonatedById": "cm4k7x2pq0001abcd1234efgh",
    "originKind": "Voorbeeld",
    "originId": "cm4k7x2pq0001abcd1234efgh",
    "ipAddress": "Voorbeeld",
    "userAgent": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## identityDocumentScan [#identitydocumentscan]

### `identityDocumentScan:completed` [#identitydocumentscan-completed]

ID-scan voltooid.

- **Permissie:** `identity-document-scans:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `identityDocumentScan:deleted` [#identitydocumentscan-deleted]

ID-scan verwijderd.

- **Permissie:** `identity-document-scans:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "identityDocumentScan:deleted",
  "data": {
    "scanId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `identityDocumentScan:linked` [#identitydocumentscan-linked]

ID-scan gekoppeld aan een klant.

- **Permissie:** `identity-document-scans:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "identityDocumentScan:linked",
  "data": {
    "scanId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "contactId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `identityDocumentScan:pendingQueueChanged` [#identitydocumentscan-pendingqueuechanged]

Wachtrij voor ID-scans gewijzigd.

- **Permissie:** `identity-document-scans:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `identityDocumentScan:unlinked` [#identitydocumentscan-unlinked]

ID-scan ontkoppeld.

- **Permissie:** `identity-document-scans:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "identityDocumentScan:unlinked",
  "data": {
    "scanId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## img [#img]

### `img:clear-tablet` [#img-clear-tablet]

Afbeelding gewist van een tablet.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `img:to-tablet` [#img-to-tablet]

Afbeelding naar een tablet gestuurd.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "img:to-tablet",
  "data": {
    "imageUrl": "https://example.com"
  }
}
```

</Accordion>
</Accordions>

## inbox [#inbox]

### `inbox:message-created` [#inbox-message-created]

Bericht ontvangen in de inbox.

- **Permissie:** `inbox:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "inbox:message-created",
  "data": {
    "threadId": "cm4k7x2pq0001abcd1234efgh",
    "messageId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `inbox:participant-reaction` [#inbox-participant-reaction]

Reactie op een inboxbericht.

- **Permissie:** `inbox:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "inbox:participant-reaction",
  "data": {
    "threadId": "cm4k7x2pq0001abcd1234efgh",
    "emoji": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

### `inbox:thread-updated` [#inbox-thread-updated]

Inboxgesprek gewijzigd.

- **Permissie:** `inbox:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "inbox:thread-updated",
  "data": {
    "threadId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `inbox:typing-changed` [#inbox-typing-changed]

- **Permissie:** `inbox:read`
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "inbox:typing-changed",
  "data": {
    "threadId": "cm4k7x2pq0001abcd1234efgh",
    "participantTyping": false,
    "staffTyping": false
  }
}
```

</Accordion>
</Accordions>

### `inbox:urgent-handoff` [#inbox-urgent-handoff]

Dringende overdracht door de assistent.

- **Permissie:** `inbox:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "inbox:urgent-handoff",
  "data": {
    "threadId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## integration-alarm [#integration-alarm]

### `integration-alarm:created` [#integration-alarm-created]

Meteralarm afgegaan.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "integration-alarm:created",
  "data": {
    "meter": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "serial": "Voorbeeld",
      "type": "ELECTRICITY",
      "provider": "MANUAL",
      "customFields": {},
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "terrainId": "cm4k7x2pq0001abcd1234efgh",
      "lastReadingId": "cm4k7x2pq0001abcd1234efgh",
      "manualMetadata": {},
      "meterCabinetId": "cm4k7x2pq0001abcd1234efgh"
    },
    "alarm": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "externalId": "cm4k7x2pq0001abcd1234efgh",
      "message": "Voorbeeld",
      "startedAt": "2026-01-15T09:30:00.000Z",
      "resolvedAt": "2026-01-15T09:30:00.000Z",
      "metadata": {},
      "meterId": "cm4k7x2pq0001abcd1234efgh",
      "icyControllerId": "cm4k7x2pq0001abcd1234efgh",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

### `integration-alarm:resolved` [#integration-alarm-resolved]

Meteralarm opgelost.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "integration-alarm:resolved",
  "data": {
    "meter": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "serial": "Voorbeeld",
      "type": "ELECTRICITY",
      "provider": "MANUAL",
      "customFields": {},
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "terrainId": "cm4k7x2pq0001abcd1234efgh",
      "lastReadingId": "cm4k7x2pq0001abcd1234efgh",
      "manualMetadata": {},
      "meterCabinetId": "cm4k7x2pq0001abcd1234efgh"
    },
    "alarm": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "externalId": "cm4k7x2pq0001abcd1234efgh",
      "message": "Voorbeeld",
      "startedAt": "2026-01-15T09:30:00.000Z",
      "resolvedAt": "2026-01-15T09:30:00.000Z",
      "metadata": {},
      "meterId": "cm4k7x2pq0001abcd1234efgh",
      "icyControllerId": "cm4k7x2pq0001abcd1234efgh",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

## invoice [#invoice]

### `invoice:created` [#invoice-created]

Factuur aangemaakt.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "invoice:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "status": "DRAFT",
    "type": "INVOICE",
    "paymentStatus": "UNPAID",
    "invoiceDate": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "paidDate": "2026-01-15T09:30:00.000Z",
    "amountSubtotal": 12.5,
    "amountTax": 12.5,
    "amountPaid": 12.5,
    "amountTotal": 12.5,
    "amountOutstanding": 12.5,
    "note": "Voorbeeld",
    "internalNote": "Voorbeeld",
    "currency": "EUR",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "structuredCommunication": "Voorbeeld",
    "originalDisplayId": "2026-00123",
    "reversedFromInvoiceId": "cm4k7x2pq0001abcd1234efgh",
    "bookedById": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "mandateCollectionScheduledAt": "2026-01-15T09:30:00.000Z",
    "excludeFromAutomatedReminders": false,
    "excludeFromAutomatedRemindersUntil": "2026-01-15T09:30:00.000Z",
    "peppolProvider": "SCRADA",
    "peppolDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "peppolUblFolder": "Voorbeeld",
    "peppolUblKey": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

### `invoice:deleted` [#invoice-deleted]

Factuur verwijderd.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "invoice:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "status": "DRAFT",
    "type": "INVOICE",
    "paymentStatus": "UNPAID",
    "invoiceDate": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "paidDate": "2026-01-15T09:30:00.000Z",
    "amountSubtotal": 12.5,
    "amountTax": 12.5,
    "amountPaid": 12.5,
    "amountTotal": 12.5,
    "amountOutstanding": 12.5,
    "note": "Voorbeeld",
    "internalNote": "Voorbeeld",
    "currency": "EUR",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "structuredCommunication": "Voorbeeld",
    "originalDisplayId": "2026-00123",
    "reversedFromInvoiceId": "cm4k7x2pq0001abcd1234efgh",
    "bookedById": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "mandateCollectionScheduledAt": "2026-01-15T09:30:00.000Z",
    "excludeFromAutomatedReminders": false,
    "excludeFromAutomatedRemindersUntil": "2026-01-15T09:30:00.000Z",
    "peppolProvider": "SCRADA",
    "peppolDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "peppolUblFolder": "Voorbeeld",
    "peppolUblKey": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

### `invoice:moved-to-customer` [#invoice-moved-to-customer]

Factuur naar een andere klant verplaatst.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "invoice:moved-to-customer",
  "data": {
    "invoice": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "displayId": "2026-00123",
      "status": "DRAFT",
      "type": "INVOICE",
      "paymentStatus": "UNPAID",
      "invoiceDate": "2026-01-15T09:30:00.000Z",
      "dueDate": "2026-01-15T09:30:00.000Z",
      "paidDate": "2026-01-15T09:30:00.000Z",
      "amountSubtotal": 12.5,
      "amountTax": 12.5,
      "amountPaid": 12.5,
      "amountTotal": 12.5,
      "amountOutstanding": 12.5,
      "note": "Voorbeeld",
      "internalNote": "Voorbeeld",
      "currency": "EUR",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "customerId": "cm4k7x2pq0001abcd1234efgh",
      "structuredCommunication": "Voorbeeld",
      "originalDisplayId": "2026-00123",
      "reversedFromInvoiceId": "cm4k7x2pq0001abcd1234efgh",
      "bookedById": "cm4k7x2pq0001abcd1234efgh",
      "mandateId": "cm4k7x2pq0001abcd1234efgh",
      "mandateCollectionScheduledAt": "2026-01-15T09:30:00.000Z",
      "excludeFromAutomatedReminders": false,
      "excludeFromAutomatedRemindersUntil": "2026-01-15T09:30:00.000Z",
      "peppolProvider": "SCRADA",
      "peppolDocumentId": "cm4k7x2pq0001abcd1234efgh",
      "peppolUblFolder": "Voorbeeld",
      "peppolUblKey": "Voorbeeld"
    },
    "priorCustomerId": "cm4k7x2pq0001abcd1234efgh",
    "targetCustomerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `invoice:paid` [#invoice-paid]

Factuur betaald.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "invoice:paid",
  "data": {
    "invoice": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "displayId": "2026-00123",
      "status": "DRAFT",
      "type": "INVOICE",
      "paymentStatus": "UNPAID",
      "invoiceDate": "2026-01-15T09:30:00.000Z",
      "dueDate": "2026-01-15T09:30:00.000Z",
      "paidDate": "2026-01-15T09:30:00.000Z",
      "amountSubtotal": 12.5,
      "amountTax": 12.5,
      "amountPaid": 12.5,
      "amountTotal": 12.5,
      "amountOutstanding": 12.5,
      "note": "Voorbeeld",
      "internalNote": "Voorbeeld",
      "currency": "EUR",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "customerId": "cm4k7x2pq0001abcd1234efgh",
      "structuredCommunication": "Voorbeeld",
      "originalDisplayId": "2026-00123",
      "reversedFromInvoiceId": "cm4k7x2pq0001abcd1234efgh",
      "bookedById": "cm4k7x2pq0001abcd1234efgh",
      "mandateId": "cm4k7x2pq0001abcd1234efgh",
      "mandateCollectionScheduledAt": "2026-01-15T09:30:00.000Z",
      "excludeFromAutomatedReminders": false,
      "excludeFromAutomatedRemindersUntil": "2026-01-15T09:30:00.000Z",
      "peppolProvider": "SCRADA",
      "peppolDocumentId": "cm4k7x2pq0001abcd1234efgh",
      "peppolUblFolder": "Voorbeeld",
      "peppolUblKey": "Voorbeeld"
    },
    "payment": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "amount": 12.5,
      "amountRefunded": 12.5,
      "amountRemaining": 12.5,
      "currency": "EUR",
      "description": "Voorbeeld",
      "reference": "Voorbeeld",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "expiresAt": "2026-01-15T09:30:00.000Z",
      "paidAt": "2026-01-15T09:30:00.000Z",
      "delayUntil": "2026-01-15T09:30:00.000Z",
      "errorMessage": "Voorbeeld",
      "errorMessageTranslationKey": "Voorbeeld",
      "status": "PENDING",
      "method": "UNKNOWN",
      "channel": "MANUAL",
      "provider": "MOLLIE",
      "channelInfo": {},
      "accountingSoftwareProvider": "ADMISOL",
      "accountingSoftwareMetadata": {},
      "createdById": "cm4k7x2pq0001abcd1234efgh",
      "invoiceId": "cm4k7x2pq0001abcd1234efgh",
      "customerId": "cm4k7x2pq0001abcd1234efgh",
      "mandateId": "cm4k7x2pq0001abcd1234efgh",
      "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
      "paymentGroupId": "cm4k7x2pq0001abcd1234efgh"
    }
  }
}
```

</Accordion>
</Accordions>

### `invoice:updated` [#invoice-updated]

Factuur gewijzigd.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "invoice:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "status": "DRAFT",
    "type": "INVOICE",
    "paymentStatus": "UNPAID",
    "invoiceDate": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "paidDate": "2026-01-15T09:30:00.000Z",
    "amountSubtotal": 12.5,
    "amountTax": 12.5,
    "amountPaid": 12.5,
    "amountTotal": 12.5,
    "amountOutstanding": 12.5,
    "note": "Voorbeeld",
    "internalNote": "Voorbeeld",
    "currency": "EUR",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "structuredCommunication": "Voorbeeld",
    "originalDisplayId": "2026-00123",
    "reversedFromInvoiceId": "cm4k7x2pq0001abcd1234efgh",
    "bookedById": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "mandateCollectionScheduledAt": "2026-01-15T09:30:00.000Z",
    "excludeFromAutomatedReminders": false,
    "excludeFromAutomatedRemindersUntil": "2026-01-15T09:30:00.000Z",
    "peppolProvider": "SCRADA",
    "peppolDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "peppolUblFolder": "Voorbeeld",
    "peppolUblKey": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

## ledgerOpeningBalance [#ledgeropeningbalance]

### `ledgerOpeningBalance:created` [#ledgeropeningbalance-created]

Beginsaldo toegevoegd.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "ledgerOpeningBalance:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "ledger": 12.5
  }
}
```

</Accordion>
</Accordions>

### `ledgerOpeningBalance:deleted` [#ledgeropeningbalance-deleted]

Beginsaldo verwijderd.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "ledgerOpeningBalance:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "ledger": 12.5
  }
}
```

</Accordion>
</Accordions>

### `ledgerOpeningBalance:updated` [#ledgeropeningbalance-updated]

Beginsaldo gewijzigd.

- **Permissie:** `invoices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "ledgerOpeningBalance:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "ledger": 12.5
  }
}
```

</Accordion>
</Accordions>

## mandate-agreement [#mandate-agreement]

### `mandate-agreement:activated` [#mandate-agreement-activated]

Mandaat actief.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate-agreement:activated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "reference": "Voorbeeld",
    "status": "SENT",
    "locale": "nl",
    "templateVersion": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "debtorName": "Voorbeeld",
    "debtorAddress": {},
    "debtorEmail": "gast@example.com",
    "debtorPhone": "+32470123456",
    "iban": "Voorbeeld",
    "bic": "Voorbeeld",
    "creditorSnapshot": {},
    "viewTokenHash": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "signedAt": "2026-01-15T09:30:00.000Z",
    "signerIp": "Voorbeeld",
    "signerUserAgent": "Voorbeeld",
    "verificationCodeHash": "Voorbeeld",
    "codeSentAt": "2026-01-15T09:30:00.000Z",
    "verificationTarget": "Voorbeeld",
    "signatureMethod": "Voorbeeld",
    "documentSha256": "Voorbeeld",
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "selectedMethod": "UNKNOWN",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh",
    "useForUtilityBills": false,
    "failureReason": "Voorbeeld",
    "halfwayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "twoDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "expiryDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "signedOnDeviceById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `mandate-agreement:expired` [#mandate-agreement-expired]

Mandaataanvraag verlopen.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate-agreement:expired",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "reference": "Voorbeeld",
    "status": "SENT",
    "locale": "nl",
    "templateVersion": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "debtorName": "Voorbeeld",
    "debtorAddress": {},
    "debtorEmail": "gast@example.com",
    "debtorPhone": "+32470123456",
    "iban": "Voorbeeld",
    "bic": "Voorbeeld",
    "creditorSnapshot": {},
    "viewTokenHash": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "signedAt": "2026-01-15T09:30:00.000Z",
    "signerIp": "Voorbeeld",
    "signerUserAgent": "Voorbeeld",
    "verificationCodeHash": "Voorbeeld",
    "codeSentAt": "2026-01-15T09:30:00.000Z",
    "verificationTarget": "Voorbeeld",
    "signatureMethod": "Voorbeeld",
    "documentSha256": "Voorbeeld",
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "selectedMethod": "UNKNOWN",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh",
    "useForUtilityBills": false,
    "failureReason": "Voorbeeld",
    "halfwayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "twoDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "expiryDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "signedOnDeviceById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `mandate-agreement:failed` [#mandate-agreement-failed]

Mandaat geweigerd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate-agreement:failed",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "reference": "Voorbeeld",
    "status": "SENT",
    "locale": "nl",
    "templateVersion": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "debtorName": "Voorbeeld",
    "debtorAddress": {},
    "debtorEmail": "gast@example.com",
    "debtorPhone": "+32470123456",
    "iban": "Voorbeeld",
    "bic": "Voorbeeld",
    "creditorSnapshot": {},
    "viewTokenHash": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "signedAt": "2026-01-15T09:30:00.000Z",
    "signerIp": "Voorbeeld",
    "signerUserAgent": "Voorbeeld",
    "verificationCodeHash": "Voorbeeld",
    "codeSentAt": "2026-01-15T09:30:00.000Z",
    "verificationTarget": "Voorbeeld",
    "signatureMethod": "Voorbeeld",
    "documentSha256": "Voorbeeld",
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "selectedMethod": "UNKNOWN",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh",
    "useForUtilityBills": false,
    "failureReason": "Voorbeeld",
    "halfwayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "twoDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "expiryDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "signedOnDeviceById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `mandate-agreement:signed` [#mandate-agreement-signed]

Mandaat ondertekend.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate-agreement:signed",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "reference": "Voorbeeld",
    "status": "SENT",
    "locale": "nl",
    "templateVersion": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "debtorName": "Voorbeeld",
    "debtorAddress": {},
    "debtorEmail": "gast@example.com",
    "debtorPhone": "+32470123456",
    "iban": "Voorbeeld",
    "bic": "Voorbeeld",
    "creditorSnapshot": {},
    "viewTokenHash": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "signedAt": "2026-01-15T09:30:00.000Z",
    "signerIp": "Voorbeeld",
    "signerUserAgent": "Voorbeeld",
    "verificationCodeHash": "Voorbeeld",
    "codeSentAt": "2026-01-15T09:30:00.000Z",
    "verificationTarget": "Voorbeeld",
    "signatureMethod": "Voorbeeld",
    "documentSha256": "Voorbeeld",
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "selectedMethod": "UNKNOWN",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh",
    "useForUtilityBills": false,
    "failureReason": "Voorbeeld",
    "halfwayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "twoDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "expiryDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "signedOnDeviceById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `mandate-agreement:updated` [#mandate-agreement-updated]

Mandaataanvraag gewijzigd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate-agreement:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "reference": "Voorbeeld",
    "status": "SENT",
    "locale": "nl",
    "templateVersion": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "debtorName": "Voorbeeld",
    "debtorAddress": {},
    "debtorEmail": "gast@example.com",
    "debtorPhone": "+32470123456",
    "iban": "Voorbeeld",
    "bic": "Voorbeeld",
    "creditorSnapshot": {},
    "viewTokenHash": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "signedAt": "2026-01-15T09:30:00.000Z",
    "signerIp": "Voorbeeld",
    "signerUserAgent": "Voorbeeld",
    "verificationCodeHash": "Voorbeeld",
    "codeSentAt": "2026-01-15T09:30:00.000Z",
    "verificationTarget": "Voorbeeld",
    "signatureMethod": "Voorbeeld",
    "documentSha256": "Voorbeeld",
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "selectedMethod": "UNKNOWN",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh",
    "useForUtilityBills": false,
    "failureReason": "Voorbeeld",
    "halfwayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "twoDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "expiryDayReminderSentAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "signedOnDeviceById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## mandate [#mandate]

### `mandate:created` [#mandate-created]

Mandaat aangemaakt.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "status": "PENDING",
    "provider": "MOLLIE",
    "paymentMethod": "UNKNOWN",
    "providerInfo": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "maximumAmount": 12.5,
    "currency": "EUR",
    "lastUsedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `mandate:deleted` [#mandate-deleted]

Mandaat verwijderd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "status": "PENDING",
    "provider": "MOLLIE",
    "paymentMethod": "UNKNOWN",
    "providerInfo": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "maximumAmount": 12.5,
    "currency": "EUR",
    "lastUsedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `mandate:updated` [#mandate-updated]

Mandaat gewijzigd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "mandate:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "status": "PENDING",
    "provider": "MOLLIE",
    "paymentMethod": "UNKNOWN",
    "providerInfo": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "maximumAmount": 12.5,
    "currency": "EUR",
    "lastUsedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "setupPaymentId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## meter [#meter]

### `meter:created` [#meter-created]

Meter aangemaakt.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `meter:updated` [#meter-updated]

Meter gewijzigd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

## meterAnomaly [#meteranomaly]

### `meterAnomaly:detected` [#meteranomaly-detected]

Meterafwijking vastgesteld.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterAnomaly:detected",
  "data": {
    "meter": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "serial": "Voorbeeld",
      "type": "ELECTRICITY",
      "provider": "MANUAL",
      "customFields": {},
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "terrainId": "cm4k7x2pq0001abcd1234efgh",
      "lastReadingId": "cm4k7x2pq0001abcd1234efgh",
      "manualMetadata": {},
      "meterCabinetId": "cm4k7x2pq0001abcd1234efgh"
    },
    "anomaly": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "kind": "FLAT_WHILE_PRESENT",
      "detectedAt": "2026-01-15T09:30:00.000Z",
      "resolvedAt": "2026-01-15T09:30:00.000Z",
      "flatSince": "2026-01-15T09:30:00.000Z",
      "lastReadingAt": "2026-01-15T09:30:00.000Z",
      "lastReadingValue": 12.5,
      "presenceDays": 1,
      "expectedConsumption": 12.5,
      "observedConsumption": 12.5,
      "meterId": "cm4k7x2pq0001abcd1234efgh",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

### `meterAnomaly:resolved` [#meteranomaly-resolved]

Meterafwijking opgelost.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterAnomaly:resolved",
  "data": {
    "meter": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "serial": "Voorbeeld",
      "type": "ELECTRICITY",
      "provider": "MANUAL",
      "customFields": {},
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "terrainId": "cm4k7x2pq0001abcd1234efgh",
      "lastReadingId": "cm4k7x2pq0001abcd1234efgh",
      "manualMetadata": {},
      "meterCabinetId": "cm4k7x2pq0001abcd1234efgh"
    },
    "anomaly": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "kind": "FLAT_WHILE_PRESENT",
      "detectedAt": "2026-01-15T09:30:00.000Z",
      "resolvedAt": "2026-01-15T09:30:00.000Z",
      "flatSince": "2026-01-15T09:30:00.000Z",
      "lastReadingAt": "2026-01-15T09:30:00.000Z",
      "lastReadingValue": 12.5,
      "presenceDays": 1,
      "expectedConsumption": 12.5,
      "observedConsumption": 12.5,
      "meterId": "cm4k7x2pq0001abcd1234efgh",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

## meterConsumptionBatch [#meterconsumptionbatch]

### `meterConsumptionBatch:created` [#meterconsumptionbatch-created]

Verbruiksperiode gestart.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterConsumptionBatch:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "startReadingId": "cm4k7x2pq0001abcd1234efgh",
    "endReadingId": "cm4k7x2pq0001abcd1234efgh",
    "consumption": 12.5,
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "closed": false,
    "invoiced": false,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `meterConsumptionBatch:updated` [#meterconsumptionbatch-updated]

Verbruiksperiode gewijzigd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterConsumptionBatch:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "startReadingId": "cm4k7x2pq0001abcd1234efgh",
    "endReadingId": "cm4k7x2pq0001abcd1234efgh",
    "consumption": 12.5,
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "closed": false,
    "invoiced": false,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## meterReading [#meterreading]

### `meterReading:created` [#meterreading-created]

Meterstand ingevoerd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterReading:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "value": 12.5,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "readingAt": "2026-01-15T09:30:00.000Z",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `meterReading:deleted` [#meterreading-deleted]

Meterstand verwijderd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterReading:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "value": 12.5,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "readingAt": "2026-01-15T09:30:00.000Z",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `meterReading:synced` [#meterreading-synced]

Meterstand gesynchroniseerd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterReading:synced",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "value": 12.5,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "readingAt": "2026-01-15T09:30:00.000Z",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `meterReading:updated` [#meterreading-updated]

Meterstand gewijzigd.

- **Permissie:** `meters:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "meterReading:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "value": 12.5,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "readingAt": "2026-01-15T09:30:00.000Z",
    "meterId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## nativeDevice [#nativedevice]

### `nativeDevice:command` [#nativedevice-command]

- **Permissie:** `native-devices:read`
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nativeDevice:command",
  "data": {
    "installationId": "cm4k7x2pq0001abcd1234efgh",
    "url": "https://example.com"
  }
}
```

</Accordion>
</Accordions>

### `nativeDevice:config` [#nativedevice-config]

- **Permissie:** `native-devices:read`
- **Levering:** SSE, geen webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `nativeDevice:deleted` [#nativedevice-deleted]

Tablet of kiosk verwijderd.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nativeDevice:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## nfc-tag-transaction [#nfc-tag-transaction]

### `nfc-tag-transaction:changed` [#nfc-tag-transaction-changed]

NFC-tagtransactie gewijzigd.

- **Permissie:** `nfc-tag-transactions:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nfc-tag-transaction:changed",
  "data": {
    "transactionId": "cm4k7x2pq0001abcd1234efgh",
    "nfcTagId": "cm4k7x2pq0001abcd1234efgh",
    "status": "PENDING"
  }
}
```

</Accordion>
</Accordions>

## nfc-tag [#nfc-tag]

### `nfc-tag:blocked` [#nfc-tag-blocked]

NFC-tag geblokkeerd.

- **Permissie:** `nfc-tags:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nfc-tag:blocked",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "uid": "Voorbeeld",
    "type": "CARD",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "balance": 12.5,
    "metadata": {},
    "blockedAt": "2026-01-15T09:30:00.000Z",
    "activatedFrom": "2026-01-15T09:30:00.000Z",
    "activatedUntil": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `nfc-tag:presented` [#nfc-tag-presented]

NFC-tag aangeboden.

- **Permissie:** `nfc-tags:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nfc-tag:presented",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "uid": "Voorbeeld",
    "type": "CARD",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "balance": 12.5,
    "metadata": {},
    "blockedAt": "2026-01-15T09:30:00.000Z",
    "activatedFrom": "2026-01-15T09:30:00.000Z",
    "activatedUntil": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `nfc-tag:unblocked` [#nfc-tag-unblocked]

NFC-tag gedeblokkeerd.

- **Permissie:** `nfc-tags:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nfc-tag:unblocked",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "uid": "Voorbeeld",
    "type": "CARD",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "balance": 12.5,
    "metadata": {},
    "blockedAt": "2026-01-15T09:30:00.000Z",
    "activatedFrom": "2026-01-15T09:30:00.000Z",
    "activatedUntil": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `nfc-tag:updated` [#nfc-tag-updated]

NFC-tag gewijzigd.

- **Permissie:** `nfc-tags:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "nfc-tag:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "uid": "Voorbeeld",
    "type": "CARD",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "balance": 12.5,
    "metadata": {},
    "blockedAt": "2026-01-15T09:30:00.000Z",
    "activatedFrom": "2026-01-15T09:30:00.000Z",
    "activatedUntil": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## notification-delivery [#notification-delivery]

### `notification-delivery:deleted` [#notification-delivery-deleted]

Melding verwijderd.

- **Permissie:** `notifications:deliveries:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "notification-delivery:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "notificationType": "NEW_INVOICE_NOTIFICATION",
    "notificationName": "Voorbeeld",
    "metadata": {},
    "source": "INTERNAL",
    "externalSource": "Voorbeeld",
    "externalReference": "Voorbeeld",
    "createdByApiKeyId": "cm4k7x2pq0001abcd1234efgh",
    "createdByApiKeyName": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "triggeredByUserId": "cm4k7x2pq0001abcd1234efgh",
    "recipientUserId": "cm4k7x2pq0001abcd1234efgh",
    "recipientReadAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `notification-delivery:updated` [#notification-delivery-updated]

Status van melding gewijzigd.

- **Permissie:** `notifications:deliveries:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "notification-delivery:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "notificationType": "NEW_INVOICE_NOTIFICATION",
    "notificationName": "Voorbeeld",
    "metadata": {},
    "source": "INTERNAL",
    "externalSource": "Voorbeeld",
    "externalReference": "Voorbeeld",
    "createdByApiKeyId": "cm4k7x2pq0001abcd1234efgh",
    "createdByApiKeyName": "Voorbeeld",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "paymentId": "cm4k7x2pq0001abcd1234efgh",
    "triggeredByUserId": "cm4k7x2pq0001abcd1234efgh",
    "recipientUserId": "cm4k7x2pq0001abcd1234efgh",
    "recipientReadAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## notificationInbox [#notificationinbox]

### `notificationInbox:created` [#notificationinbox-created]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "notificationInbox:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "notificationType": "NEW_INVOICE_NOTIFICATION",
    "title": "Voorbeeld",
    "body": "Voorbeeld",
    "url": "https://example.com",
    "urgent": false,
    "hasEmail": false,
    "readAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `notificationInbox:read` [#notificationinbox-read]

- **Permissie:** elk lid
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "notificationInbox:read",
  "data": {
    "readAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## occupation [#occupation]

### `occupation:ended` [#occupation-ended]

Bezetting beëindigd.

- **Permissie:** `terrains:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "occupation:ended",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "occupationType": "OWN_ACCOMMODATION",
    "rentPeriod": {},
    "price": 12.5,
    "description": "Voorbeeld",
    "paidUntil": "2026-01-15T09:30:00.000Z",
    "invoicedUntil": "2026-01-15T09:30:00.000Z",
    "customFields": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "reservationId": "cm4k7x2pq0001abcd1234efgh",
    "terrainId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## organizationSettings [#organizationsettings]

### `organizationSettings:updated` [#organizationsettings-updated]

Instellingen gewijzigd.

- **Permissie:** `organization:settings:read` of `organization:settings:write`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "organizationSettings:updated",
  "data": {
    "openingHoursChanged": false
  }
}
```

</Accordion>
</Accordions>

## payment-group [#payment-group]

### `payment-group:assigned-to-invoice` [#payment-group-assigned-to-invoice]

Betalingsgroep gekoppeld aan een factuur.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:assigned-to-invoice",
  "data": {
    "paymentGroup": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "description": "Voorbeeld",
      "status": "OPEN",
      "metadata": {},
      "invoiceId": "cm4k7x2pq0001abcd1234efgh",
      "assignedAt": "2026-01-15T09:30:00.000Z",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    },
    "invoiceId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `payment-group:created` [#payment-group-created]

Betalingsgroep aangemaakt.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "OPEN",
    "metadata": {},
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "assignedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `payment-group:deleted` [#payment-group-deleted]

Betalingsgroep verwijderd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `payment-group:payments-added` [#payment-group-payments-added]

Betalingen toegevoegd aan een groep.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:payments-added",
  "data": {
    "paymentGroup": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "description": "Voorbeeld",
      "status": "OPEN",
      "metadata": {},
      "invoiceId": "cm4k7x2pq0001abcd1234efgh",
      "assignedAt": "2026-01-15T09:30:00.000Z",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

### `payment-group:payments-removed` [#payment-group-payments-removed]

Betalingen verwijderd uit een groep.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:payments-removed",
  "data": {
    "paymentGroup": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "description": "Voorbeeld",
      "status": "OPEN",
      "metadata": {},
      "invoiceId": "cm4k7x2pq0001abcd1234efgh",
      "assignedAt": "2026-01-15T09:30:00.000Z",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    }
  }
}
```

</Accordion>
</Accordions>

### `payment-group:unassigned-from-invoice` [#payment-group-unassigned-from-invoice]

Betalingsgroep ontkoppeld van een factuur.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:unassigned-from-invoice",
  "data": {
    "paymentGroup": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "description": "Voorbeeld",
      "status": "OPEN",
      "metadata": {},
      "invoiceId": "cm4k7x2pq0001abcd1234efgh",
      "assignedAt": "2026-01-15T09:30:00.000Z",
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z"
    },
    "previousInvoiceId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `payment-group:updated` [#payment-group-updated]

Betalingsgroep gewijzigd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-group:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "OPEN",
    "metadata": {},
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "assignedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## payment-report [#payment-report]

### `payment-report:created` [#payment-report-created]

Betalingsrapport aangemaakt.

- **Permissie:** `payment-reports:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-report:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "reportDate": "2026-01-15T09:30:00.000Z",
    "status": "CONCEPT",
    "totalAmount": 12.5,
    "paymentCount": 1,
    "mollieSettlementId": "cm4k7x2pq0001abcd1234efgh",
    "mollieSettlement": {},
    "metadata": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `payment-report:updated` [#payment-report-updated]

Betalingsrapport gewijzigd.

- **Permissie:** `payment-reports:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment-report:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "reportDate": "2026-01-15T09:30:00.000Z",
    "status": "CONCEPT",
    "totalAmount": 12.5,
    "paymentCount": 1,
    "mollieSettlementId": "cm4k7x2pq0001abcd1234efgh",
    "mollieSettlement": {},
    "metadata": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## payment [#payment]

### `payment:created` [#payment-created]

Betaling aangemaakt.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "amount": 12.5,
    "amountRefunded": 12.5,
    "amountRemaining": 12.5,
    "currency": "EUR",
    "description": "Voorbeeld",
    "reference": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "paidAt": "2026-01-15T09:30:00.000Z",
    "delayUntil": "2026-01-15T09:30:00.000Z",
    "errorMessage": "Voorbeeld",
    "errorMessageTranslationKey": "Voorbeeld",
    "status": "PENDING",
    "method": "UNKNOWN",
    "channel": "MANUAL",
    "provider": "MOLLIE",
    "channelInfo": {},
    "accountingSoftwareProvider": "ADMISOL",
    "accountingSoftwareMetadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "paymentGroupId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `payment:deleted` [#payment-deleted]

Betaling verwijderd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "amount": 12.5,
    "amountRefunded": 12.5,
    "amountRemaining": 12.5,
    "currency": "EUR",
    "description": "Voorbeeld",
    "reference": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "paidAt": "2026-01-15T09:30:00.000Z",
    "delayUntil": "2026-01-15T09:30:00.000Z",
    "errorMessage": "Voorbeeld",
    "errorMessageTranslationKey": "Voorbeeld",
    "status": "PENDING",
    "method": "UNKNOWN",
    "channel": "MANUAL",
    "provider": "MOLLIE",
    "channelInfo": {},
    "accountingSoftwareProvider": "ADMISOL",
    "accountingSoftwareMetadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "paymentGroupId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `payment:updated` [#payment-updated]

Betaling gewijzigd.

- **Permissie:** `payments:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "payment:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "amount": 12.5,
    "amountRefunded": 12.5,
    "amountRemaining": 12.5,
    "currency": "EUR",
    "description": "Voorbeeld",
    "reference": "Voorbeeld",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "paidAt": "2026-01-15T09:30:00.000Z",
    "delayUntil": "2026-01-15T09:30:00.000Z",
    "errorMessage": "Voorbeeld",
    "errorMessageTranslationKey": "Voorbeeld",
    "status": "PENDING",
    "method": "UNKNOWN",
    "channel": "MANUAL",
    "provider": "MOLLIE",
    "channelInfo": {},
    "accountingSoftwareProvider": "ADMISOL",
    "accountingSoftwareMetadata": {},
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "mandateId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "paymentGroupId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## pdf [#pdf]

### `pdf:clear-tablet` [#pdf-clear-tablet]

Pdf gewist van een tablet.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `pdf:to-tablet` [#pdf-to-tablet]

Pdf naar een tablet gestuurd.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "pdf:to-tablet",
  "data": {
    "pdfUrl": "https://example.com"
  }
}
```

</Accordion>
</Accordions>

## print-queue-job [#print-queue-job]

### `print-queue-job:updated` [#print-queue-job-updated]

Printopdracht gewijzigd.

- **Permissie:** `printing:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "print-queue-job:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "type": "INVOICE_A4",
    "referenceId": "cm4k7x2pq0001abcd1234efgh",
    "status": "PENDING",
    "invoiceId": "cm4k7x2pq0001abcd1234efgh",
    "paymentReportId": "cm4k7x2pq0001abcd1234efgh",
    "accessMethodId": "cm4k7x2pq0001abcd1234efgh",
    "identityDocumentScanId": "cm4k7x2pq0001abcd1234efgh",
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "documentId": "cm4k7x2pq0001abcd1234efgh",
    "pdfUrl": "https://example.com",
    "scheduledAt": "2026-01-15T09:30:00.000Z",
    "attemptCount": 1,
    "lastError": "Voorbeeld",
    "claimedAt": "2026-01-15T09:30:00.000Z",
    "finishedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## product [#product]

### `product:created` [#product-created]

Product aangemaakt.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `product:deleted` [#product-deleted]

Product verwijderd.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `product:updated` [#product-updated]

Product gewijzigd.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

## productPriceChange [#productpricechange]

### `productPriceChange:applied` [#productpricechange-applied]

Geplande productprijs toegepast.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "productPriceChange:applied",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "productId": "cm4k7x2pq0001abcd1234efgh",
    "effectiveFrom": "2026-01-15T09:30:00.000Z",
    "amountPerUnit": 12.5,
    "taxPercentage": 12.5,
    "taxRegime": "STANDARD",
    "appliedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `productPriceChange:created` [#productpricechange-created]

Productprijs gepland.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "productPriceChange:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "productId": "cm4k7x2pq0001abcd1234efgh",
    "effectiveFrom": "2026-01-15T09:30:00.000Z",
    "amountPerUnit": 12.5,
    "taxPercentage": 12.5,
    "taxRegime": "STANDARD",
    "appliedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `productPriceChange:deleted` [#productpricechange-deleted]

Geplande productprijs verwijderd.

- **Permissie:** `products:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "productPriceChange:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "productId": "cm4k7x2pq0001abcd1234efgh",
    "effectiveFrom": "2026-01-15T09:30:00.000Z",
    "amountPerUnit": 12.5,
    "taxPercentage": 12.5,
    "taxRegime": "STANDARD",
    "appliedAt": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## reservation [#reservation]

### `reservation:created` [#reservation-created]

Reservering aangemaakt.

- **Permissie:** `reservations:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "reservation:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "status": "BOOKED",
    "note": "Voorbeeld",
    "checkIn": "2026-01-15T09:30:00.000Z",
    "checkOut": "2026-01-15T09:30:00.000Z",
    "checkedInAt": "2026-01-15T09:30:00.000Z",
    "checkedOutAt": "2026-01-15T09:30:00.000Z",
    "canceledAt": "2026-01-15T09:30:00.000Z",
    "numberOfToddlers": 1,
    "numberOfChildren": 1,
    "numberOfAdults": 1,
    "numberOfAnimals": 1,
    "paidUntil": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "preferredTerrainId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "customFields": {},
    "allowOnlinePayments": false,
    "sendConfirmationEmails": false
  }
}
```

</Accordion>
</Accordions>

### `reservation:updated` [#reservation-updated]

Reservering gewijzigd.

- **Permissie:** `reservations:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "reservation:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "displayId": "2026-00123",
    "status": "BOOKED",
    "note": "Voorbeeld",
    "checkIn": "2026-01-15T09:30:00.000Z",
    "checkOut": "2026-01-15T09:30:00.000Z",
    "checkedInAt": "2026-01-15T09:30:00.000Z",
    "checkedOutAt": "2026-01-15T09:30:00.000Z",
    "canceledAt": "2026-01-15T09:30:00.000Z",
    "numberOfToddlers": 1,
    "numberOfChildren": 1,
    "numberOfAdults": 1,
    "numberOfAnimals": 1,
    "paidUntil": "2026-01-15T09:30:00.000Z",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "preferredTerrainId": "cm4k7x2pq0001abcd1234efgh",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "customFields": {},
    "allowOnlinePayments": false,
    "sendConfirmationEmails": false
  }
}
```

</Accordion>
</Accordions>

## sign [#sign]

### `sign:clear-tablet` [#sign-clear-tablet]

Ondertekening gewist van een tablet.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

### `sign:to-tablet` [#sign-to-tablet]

Ondertekening naar een tablet gestuurd.

- **Permissie:** `native-devices:read`
- **Levering:** SSE + webhook

De vorm van `data` is geen databaserecord en wordt niet automatisch beschreven.

## signatureRequest [#signaturerequest]

### `signatureRequest:completed` [#signaturerequest-completed]

Ondertekenverzoek afgerond.

- **Permissie:** `signature-requests:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "signatureRequest:completed",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "title": "Voorbeeld",
    "message": "Voorbeeld",
    "status": "DRAFT",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "sourceDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "sourceKey": "Voorbeeld",
    "sourceSha256": "Voorbeeld",
    "pageCount": 1,
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "signedSha256": "Voorbeeld",
    "stampedSha256": "Voorbeeld",
    "sealFingerprint": "Voorbeeld",
    "timestampedAt": "2026-01-15T09:30:00.000Z",
    "timestampAuthority": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "reminderAfterDays": 1,
    "sentAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `signatureRequest:deleted` [#signaturerequest-deleted]

Ondertekenverzoek verwijderd.

- **Permissie:** `signature-requests:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "signatureRequest:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "title": "Voorbeeld",
    "message": "Voorbeeld",
    "status": "DRAFT",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "sourceDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "sourceKey": "Voorbeeld",
    "sourceSha256": "Voorbeeld",
    "pageCount": 1,
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "signedSha256": "Voorbeeld",
    "stampedSha256": "Voorbeeld",
    "sealFingerprint": "Voorbeeld",
    "timestampedAt": "2026-01-15T09:30:00.000Z",
    "timestampAuthority": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "reminderAfterDays": 1,
    "sentAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `signatureRequest:updated` [#signaturerequest-updated]

Ondertekenverzoek gewijzigd.

- **Permissie:** `signature-requests:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "signatureRequest:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "title": "Voorbeeld",
    "message": "Voorbeeld",
    "status": "DRAFT",
    "customerId": "cm4k7x2pq0001abcd1234efgh",
    "sourceDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "sourceKey": "Voorbeeld",
    "sourceSha256": "Voorbeeld",
    "pageCount": 1,
    "signedDocumentId": "cm4k7x2pq0001abcd1234efgh",
    "signedSha256": "Voorbeeld",
    "stampedSha256": "Voorbeeld",
    "sealFingerprint": "Voorbeeld",
    "timestampedAt": "2026-01-15T09:30:00.000Z",
    "timestampAuthority": "Voorbeeld",
    "expiresAt": "2026-01-15T09:30:00.000Z",
    "reminderAfterDays": 1,
    "sentAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "createdById": "cm4k7x2pq0001abcd1234efgh",
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## task-time-tracker [#task-time-tracker]

### `task-time-tracker:changed` [#task-time-tracker-changed]

- **Permissie:** `tasks:read`
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task-time-tracker:changed",
  "data": {
    "taskId": "cm4k7x2pq0001abcd1234efgh",
    "previousTaskId": "cm4k7x2pq0001abcd1234efgh",
    "cleared": false,
    "id": "cm4k7x2pq0001abcd1234efgh",
    "userId": "cm4k7x2pq0001abcd1234efgh",
    "note": "Voorbeeld",
    "accumulatedMs": 12.5,
    "runningSince": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## task-view [#task-view]

### `task-view:created` [#task-view-created]

Takenweergave aangemaakt.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task-view:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "icon": "Voorbeeld",
    "color": "Voorbeeld",
    "kind": "MANUAL",
    "scope": "PERSONAL",
    "ownerId": "cm4k7x2pq0001abcd1234efgh",
    "sortOrder": 1,
    "definition": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `task-view:deleted` [#task-view-deleted]

Takenweergave verwijderd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task-view:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "icon": "Voorbeeld",
    "color": "Voorbeeld",
    "kind": "MANUAL",
    "scope": "PERSONAL",
    "ownerId": "cm4k7x2pq0001abcd1234efgh",
    "sortOrder": 1,
    "definition": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

### `task-view:membership-changed` [#task-view-membership-changed]

Taken in een weergave gewijzigd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task-view:membership-changed",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task-view:updated` [#task-view-updated]

Takenweergave gewijzigd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task-view:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "icon": "Voorbeeld",
    "color": "Voorbeeld",
    "kind": "MANUAL",
    "scope": "PERSONAL",
    "ownerId": "cm4k7x2pq0001abcd1234efgh",
    "sortOrder": 1,
    "definition": {},
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>

## task [#task]

### `task:action-chosen` [#task-action-chosen]

Taakactie gekozen.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:action-chosen",
  "data": {
    "task": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "name": "Voorbeeld",
      "description": "Voorbeeld",
      "status": "PENDING",
      "priority": "LOW",
      "sortOrder": 1,
      "createdAt": "2026-01-15T09:30:00.000Z",
      "updatedAt": "2026-01-15T09:30:00.000Z",
      "completedAt": "2026-01-15T09:30:00.000Z",
      "dueDate": "2026-01-15T09:30:00.000Z",
      "remindAt": "2026-01-15T09:30:00.000Z",
      "reminderSentAt": "2026-01-15T09:30:00.000Z",
      "remindByEmail": false,
      "remindByPush": false,
      "remindRrule": "Voorbeeld",
      "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
      "commentId": "cm4k7x2pq0001abcd1234efgh",
      "parentId": "cm4k7x2pq0001abcd1234efgh",
      "metadata": {},
      "customFields": {},
      "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
      "actionChosenAt": "2026-01-15T09:30:00.000Z",
      "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
      "actionNote": "Voorbeeld",
      "completionLocked": false,
      "createdById": "cm4k7x2pq0001abcd1234efgh"
    },
    "action": {
      "id": "cm4k7x2pq0001abcd1234efgh",
      "taskId": "cm4k7x2pq0001abcd1234efgh",
      "label": "Voorbeeld",
      "color": "Voorbeeld",
      "icon": "Voorbeeld",
      "position": 1,
      "key": "Voorbeeld",
      "requiresNote": false,
      "requiresConfirmation": false,
      "confirmTitle": "Voorbeeld",
      "confirmDescription": "Voorbeeld",
      "confirmLevel": "Voorbeeld",
      "automationId": "cm4k7x2pq0001abcd1234efgh"
    },
    "note": "Voorbeeld"
  }
}
```

</Accordion>
</Accordions>

### `task:assigned` [#task-assigned]

Taak toegewezen.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:assigned",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task:created` [#task-created]

Taak aangemaakt.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:created",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task:deleted` [#task-deleted]

Taak verwijderd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:deleted",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task:status-changed` [#task-status-changed]

Taakstatus gewijzigd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:status-changed",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task:unassigned` [#task-unassigned]

Taaktoewijzing opgeheven.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:unassigned",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

### `task:updated` [#task-updated]

Taak gewijzigd.

- **Permissie:** `tasks:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "task:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "status": "PENDING",
    "priority": "LOW",
    "sortOrder": 1,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "completedAt": "2026-01-15T09:30:00.000Z",
    "dueDate": "2026-01-15T09:30:00.000Z",
    "remindAt": "2026-01-15T09:30:00.000Z",
    "reminderSentAt": "2026-01-15T09:30:00.000Z",
    "remindByEmail": false,
    "remindByPush": false,
    "remindRrule": "Voorbeeld",
    "deadlineNotifiedAt": "2026-01-15T09:30:00.000Z",
    "commentId": "cm4k7x2pq0001abcd1234efgh",
    "parentId": "cm4k7x2pq0001abcd1234efgh",
    "metadata": {},
    "customFields": {},
    "chosenActionId": "cm4k7x2pq0001abcd1234efgh",
    "actionChosenAt": "2026-01-15T09:30:00.000Z",
    "actionChosenById": "cm4k7x2pq0001abcd1234efgh",
    "actionNote": "Voorbeeld",
    "completionLocked": false,
    "createdById": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## terrain [#terrain]

### `terrain:updated` [#terrain-updated]

Terrein gewijzigd.

- **Permissie:** `terrains:read`
- **Levering:** SSE + webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "terrain:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "name": "Voorbeeld",
    "description": "Voorbeeld",
    "bookable": false,
    "createdAt": "2026-01-15T09:30:00.000Z",
    "updatedAt": "2026-01-15T09:30:00.000Z",
    "geoJson": {},
    "surfaceArea": 12.5,
    "metadata": {},
    "customFields": {},
    "calculatedTariff": {},
    "terrainTypeId": "cm4k7x2pq0001abcd1234efgh"
  }
}
```

</Accordion>
</Accordions>

## vehiclePresence [#vehiclepresence]

### `vehiclePresence:updated` [#vehiclepresence-updated]

- **Permissie:** `access-control:read`
- **Levering:** SSE, geen webhook

<Accordions>
<Accordion title="Voorbeeld-payload">

```json
{
  "event": "vehiclePresence:updated",
  "data": {
    "id": "cm4k7x2pq0001abcd1234efgh",
    "plate": "Voorbeeld",
    "status": "INSIDE",
    "lastSeenAt": "2026-01-15T09:30:00.000Z"
  }
}
```

</Accordion>
</Accordions>


# External notifications (/en-GB/ontwikkelaars/externe-notificaties)

Does your system send its own emails to customers (newsletter, booking confirmation, reminder)? Then register them in Tillor. Staff see them on the customer, on the invoice and in the **Notifications** overview, next to the notifications Tillor sends itself.

Tillor **sends nothing**: you register a message that has already been sent. External notifications always carry the label **External** with your source name in the app, so they never pass for a Tillor notification.

## Access [#toegang]

The user behind the [API key](/ontwikkelaars/http) needs one of these permissions in the organisation. An administrator grants them in the organisation's user permissions, in the **Notifications** group (**Register external notifications** and **Manage other external notifications**).

| Permission | What you can do |
|-----------|------------|
| `notifications:external:write` | Register notifications and update or delete your **own** registrations |
| `notifications:external:manage-others` | Also update or delete registrations of other users or integrations |

<Callout type="info" title="One user per integration">
Ownership is tied to the user of the API key. Use a separate (service) user per integration, so one integration can never change the notifications of another.
</Callout>

## Endpoints [#endpoints]

All paths are under `/api/orgs/:orgId`. Exact schemas: [OpenAPI](https://tillor.eu/api/openapi.json), tag `notifications`.

| Method | Path | Description |
|--------|-----|--------------|
| POST | `/notifications/external` | Register a notification |
| PATCH | `/notifications/external/{id}` | Update status, timestamps or content |
| DELETE | `/notifications/external/{id}` | Delete permanently |
| GET | `/notifications?source=EXTERNAL` | List registered notifications (also filter on `externalSource`, `externalReference`, `customerId`, `invoiceId`) |
| GET | `/notifications/{id}` | Fetch one notification |

Notifications that Tillor sent itself cannot be changed or deleted through these endpoints; they return `404`.

## Register [#registreren]

```bash
curl -X POST "https://tillor.eu/api/orgs/org_abc123/notifications/external" \
  -H "x-api-key: tkn_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "externalSource": "mailchimp",
    "externalReference": "campaign-42:member-9f3a",
    "name": "Boekingsbevestiging",
    "customerId": "clx789...",
    "channel": "EMAIL",
    "status": "SENT",
    "sentAt": "2026-09-19T08:15:00Z",
    "email": {
      "to": "jan@voorbeeld.nl",
      "from": "Recreatiepark Het Meer <info@recreatiepark-het-meer.be>",
      "subject": "Je boeking is bevestigd",
      "htmlBody": "<p>Dag Jan, ...</p>",
      "attachments": [{ "filename": "bevestiging.pdf", "contentType": "application/pdf", "size": 48211 }]
    }
  }'
```

All fields and limits are in [OpenAPI](https://tillor.eu/api/openapi.json). These fields have rules you need to know beforehand:

| Field | Rule |
|------|-------|
| `externalSource` | Name of your system in lowercase letters, digits, `.`, `_` or `-` (e.g. `mailchimp`). Staff see this name on the notification |
| `externalReference` | Your own ID for this message, unique within `externalSource` |
| `name` | Short label for staff (e.g. "Booking confirmation"). It can be searched on |
| `customerId` / `invoiceId` | At least one of the two. Determines where the notification appears. If you only send `invoiceId`, Tillor also links the customer of that invoice. An unknown ID, or an invoice of a different customer, gives `400` |
| `status` | `SENT`, `FAILED`, `BOUNCED` or `COMPLAINED`. Without `sentAt` for `SENT`, Tillor uses the moment of registration |
| `sentAt`, `readAt`, `clickedAt` | ISO 8601 with time zone, e.g. `2026-09-19T08:15:00Z`. Other values are refused |
| `email.attachments` | Metadata only (`filename`, `contentType`, `size`). The files themselves are not stored |

### Retrying safely [#veilig-opnieuw-proberen]

`POST` is idempotent on `externalSource` + `externalReference`. If you send the same combination again (for example after a timeout), you get the **existing** notification back and nothing is changed. If you want to change something, use `PATCH`.

<Callout type="warn" title="No personal data in externalReference or name">
`externalSource`, `externalReference` and `name` are stored unencrypted because they are searched on. Use a technical ID, not an email address or name. An `externalReference` with `@` is refused. Recipient, subject, content and attachments are stored encrypted.
</Callout>

## Update and delete [#bijwerken-en-verwijderen]

With `PATCH`, send only the fields that change, for example when an email bounces afterwards:

```bash
curl -X PATCH "https://tillor.eu/api/orgs/org_abc123/notifications/external/NOTIFICATION_ID" \
  -H "x-api-key: tkn_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "status": "BOUNCED", "errorMessage": "Mailbox bestaat niet" }'
```

`DELETE` removes the notification permanently, including its content. Also use this to comply with a deletion request (GDPR).

A `PATCH` that changes nothing does nothing: no change, no event. If you change the content (label, recipient, sender, subject, text, HTML or attachments) or delete a notification, it appears in the activity log of the customer or invoice, with the user who did it. Updates of status, `readAt` or `clickedAt` do not appear there, so you can keep syncing opens and clicks.

## HTML and privacy [#html-en-privacy]

Tillor shows the HTML to staff as the customer received it, but treats it as untrusted content:

- When saving, scripts, forms, iframes, embeds and event attributes (`onclick`, ...) are removed. Links open in a new tab
- The preview runs in an isolated frame without scripts and without access to the Tillor session
- External images and fonts do **not load automatically**, so opening a notification does not trigger a tracking pixel. The staff member can load images per notification

So do not count on "opened" tracking in your system firing when a staff member views the notification.

## What Tillor does not do with external notifications [#wat-tillor-niet-doet-met-externe-notificaties]

- Does not send (again) or automatically retry
- Does not fetch status updates from your mail provider: you keep the status up to date with `PATCH`
- Does not count them in the lists **Failed Notifications**, **Bounced Notifications** and **Pending Notifications** or in the counters at the top of the notification overview, because Tillor cannot verify your status. They do appear under **Recent Communications**

## Webhooks and SSE [#webhooks-en-sse]

| Event | When |
|-------|---------|
| `notification-delivery:updated` | On registering and on every `PATCH` that changes something. Contains the full notification |
| `notification-delivery:deleted` | On `DELETE`. Contains only `id`, `source`, `externalSource`, `externalReference`, `customerId` and `invoiceId` |

The field `source` is `EXTERNAL` for your registrations and `INTERNAL` for notifications from Tillor. Filter on it if you want to skip your own events. See [Webhooks](/ontwikkelaars/webhooks) and [SSE](/ontwikkelaars/sse).

## Related [#gerelateerd]

- [HTTP API](/ontwikkelaars/http) - API keys, headers and rate limits
- [Webhooks](/ontwikkelaars/webhooks) - Receive events via HTTP POST
- [OpenAPI](https://tillor.eu/api/openapi.json) - Full schemas


# HTTP API (/en-GB/ontwikkelaars/http)

The Tillor API is a REST API. Authenticate with an API key and send the right headers with every request. API keys are **per account** - one key works for all organisations you have access to.

## API reference and OpenAPI [#api-referentie-en-openapi]

- **[API reference](/api-referentie)** - Every endpoint with parameters and examples; try requests directly in the browser
- **[OpenAPI specification](https://tillor.eu/api/openapi.json)** - Full API documentation in JSON format for code generation or import into Postman/Insomnia

---

## API keys [#api-sleutels]

### Create [#aanmaken]

You create API keys in the Tillor app via the user menu under **Account > API Keys** (marker **1** = menu, marker **2** = API Keys in the screenshot). You can also create them through the API with a logged-in session (no API key). See the [OpenAPI specification](https://tillor.eu/api/openapi.json) under tag `api-keys` for paths, request and response schemas.

<DocScreenshot src="/screenshots/http/api-keys-nav.png" alt="API keys in account settings" />

The raw key is returned **once** on creation or regeneration. Store it safely; you cannot retrieve it afterwards.

### Restrict permissions [#rechten-beperken]

By default a key can do everything you can do yourself, in every organisation you are a member of. In the key window, turn on **Limit to selected permissions** and choose the permissions the integration needs, for example only reading invoices. A restricted key gets, in each organisation, the intersection of its permissions and your membership there: a key can never do more than you. A call outside the chosen permissions gets `403 Forbidden`, just like a user without that permission. A change to the permissions applies within a minute. Through the API: `scopes` (list of permission IDs such as `invoices:read`, or `null` for everything) when creating and updating a key.

### Usage [#gebruik]

Send the API key in the `x-api-key` header:

```http
x-api-key: tkn_xxx
```

Keys use the `tkn_` prefix. For organisation endpoints the organisation ID is in the path (`/orgs/org_abc123/...`); a separate header is not needed.

### Rate limits [#rate-limits]

- **Default:** 5000 requests per 60 seconds per key
- When exceeded: `429 Too Many Requests` with `Retry-After`
- Every API key response contains IETF `RateLimit-*` headers:

```http
RateLimit-Limit: 5000
RateLimit-Remaining: 4999
RateLimit-Reset: 58
RateLimit-Policy: 5000;w=60
```

`RateLimit-Reset` is the number of seconds until the current window starts again. Browser clients can read these headers via CORS (`Access-Control-Expose-Headers`).

### Security [#beveiliging]

<Callout type="warn" title="Note">
- **Never** expose API keys in client-side code or public repositories
- Regenerate keys periodically via **Regenerate** in the app (OpenAPI: `POST /api/api-keys/:id/renew`)
- Delete unused keys with `DELETE /api/api-keys/:id`
</Callout>

---

## Base URL and organisation context [#base-url-en-organisatie-context]

**Base URL:** `https://tillor.eu` (or your deployment URL; OpenAPI mentions `{APP_URL}/api`)

**Organisation paths:** Add the organisation ID to the path:

```
/api/orgs/:orgId/...
```

**Example:**

```
GET https://tillor.eu/api/orgs/org_abc123/customers
```

**Required header for organisation endpoints:** `x-api-key: tkn_xxx`. The organisation ID is in the path.

---

## Example: cURL [#voorbeeld-curl]

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/customers" \
  -H "x-api-key: tkn_xxx" \
  -H "Content-Type: application/json"
```

---

## Integrations (marketplace) [#integraties-marketplace]

Organisation integrations (formerly "apps" in the API) use one resource per type under `/api/orgs/:orgId/integrations/{integrationType}`. Required permissions are `organization:integrations:read` and `organization:integrations:write` (replaces `organization:apps:*`).

| Method | Path | Description |
|--------|------|-------------|
| GET | `/integrations/{integrationType}` | Status (`installed`, `available`) and redacted `settings` |
| POST | `/integrations/{integrationType}` | Install (optional `settings` in body; OAuth can return `redirectUrl`) |
| PUT | `/integrations/{integrationType}` | Update settings (`settings` in body) |
| DELETE | `/integrations/{integrationType}` | Uninstall |

On `GET` and after `PUT`, `settings` contains only **public** fields plus `{ configured: true }` per secret field. Passwords, API keys and OAuth tokens are not returned. Leave secret fields empty on `PUT` to keep the existing value.

See the [OpenAPI specification](https://tillor.eu/api/openapi.json) (tag `integrations`) for exact schemas.

---

## Related [#gerelateerd]

- [API reference](/api-referentie) - Every endpoint, to try out in the browser
- [OpenAPI](https://tillor.eu/api/openapi.json) - API specification (JSON)
- [MCP](/ontwikkelaars/mcp) - Connect Cursor, Claude, ChatGPT or Gemini via OAuth
- [External notifications](/ontwikkelaars/externe-notificaties) - Register emails your own system sent
- [Webhooks](/ontwikkelaars/webhooks) - Receive events via HTTP POST
- [Incoming webhook of an automation](/ontwikkelaars/automatiseringen#een-automatisering-starten-met-een-webhook) - Start an automation with a POST, without an API key
- [SSE](/ontwikkelaars/sse) - Stream events via Server-Sent Events
- [Examples](/ontwikkelaars/voorbeelden) - Code and payload examples


# Overview (/en-GB/ontwikkelaars)

The Tillor API offers programmatic access to your organisation's data. Use API keys for authentication, webhooks for outgoing events, SSE or MQTT for realtime streaming, or MCP to connect AI tools such as Cursor, Claude, ChatGPT and Gemini to Tillor.

## What can you build? [#wat-kun-je-bouwen]

- **Integrations** - Connect Tillor to your own systems via the REST API
- **Webhooks** - Receive HTTP POST messages when events happen (invoice paid, customer created, etc.)
- **Start automations** - Start an automation from your own system with a POST to its [incoming webhook](/ontwikkelaars/automatiseringen#een-automatisering-starten-met-een-webhook)
- **Realtime dashboards** - Stream events via SSE or MQTT for live updates in your application
- **AI tools** - Let Cursor, Claude, ChatGPT or Gemini call the API via [MCP](/ontwikkelaars/mcp) (`https://mcp.tillor.dev`)

## Get started quickly [#snel-aan-de-slag]

1. **Create an API key** in Tillor under *Account > API Keys*
2. **Send the key** in the `x-api-key` header with every request
3. **Put your organisation ID in the path** of organisation endpoints: `/orgs/org_abc123/...`

<Callout type="info" title="Same events">
Webhooks and SSE deliver exactly the same events. The difference: webhooks send an HTTP POST to your URL; SSE is a long-lived connection on which you receive events.
</Callout>

**Useful links:** [API reference](/api-referentie) - [OpenAPI](https://tillor.eu/api/openapi.json)

**Scope:** API keys are per account (all organisations); webhooks are per organisation.

<Callout type="idea" title="Documentation for AI tools">
You can also use this site as text for AI tools: [`/llms.txt`](/llms.txt) (index), [`/llms-full.txt`](/llms-full.txt) (all pages together), and per page by putting `.mdx` after the path (for example [`/ontwikkelaars/http.mdx`](/ontwikkelaars/http.mdx)). **Ask AI (local)** in the doc layout loads that full export (`/llms-full.txt`) into Chrome's built-in AI, so you do not have to be on a specific page.
</Callout>

## See also [#zie-ook]

<Cards>
  <Card
    title="HTTP API"
    href="/ontwikkelaars/http"
    description="API keys, authentication, base URL and organisation context"
  />
  <Card
    title="MCP"
    href="/ontwikkelaars/mcp"
    description="Connect Cursor, Claude, ChatGPT or Gemini to Tillor via OAuth"
  />
  <Card
    title="External notifications"
    href="/ontwikkelaars/externe-notificaties"
    description="Register emails your own system sent to customers"
  />
  <Card
    title="Webhooks"
    href="/ontwikkelaars/webhooks"
    description="Receive events via HTTP POST to your endpoint"
  />
  <Card
    title="Automations"
    href="/ontwikkelaars/automatiseringen"
    description="The webhook message, the API request, incoming webhooks and the structure of a flow"
  />
  <Card
    title="SSE"
    href="/ontwikkelaars/sse"
    description="Stream realtime events via Server-Sent Events"
  />
  <Card
    title="MQTT"
    href="/ontwikkelaars/mqtt"
    description="Pub/sub via MQTT with strict topic access and JWT or static credentials"
  />
  <Card
    title="Mollie metadata"
    href="/ontwikkelaars/mollie-metadata"
    description="tillor namespace on Mollie payments"
  />
  <Card
    title="Website chat API"
    href="/ontwikkelaars/website-chat"
    description="Your own chat UI via REST and SSE"
  />
  <Card
    title="Examples"
    href="/ontwikkelaars/voorbeelden"
    description="Code and payload examples for HTTP, Webhooks and SSE"
  />
</Cards>


# MCP (/en-GB/ontwikkelaars/mcp)

With MCP (Model Context Protocol), tools such as Cursor, Claude, ChatGPT and Gemini can call the Tillor API for you. You log in once via OAuth; no API key needs to be in your config.

**URL:** `https://mcp.tillor.dev`

## What you can do with it [#wat-je-ermee-kunt]

Once connected, you can do the following in the AI tool:

1. Browse API categories and endpoints (from the OpenAPI specification)
2. Call endpoints with your own permissions in the chosen organisation

This runs over the same REST API as the [HTTP API](/ontwikkelaars/http). What you are allowed to do depends on your Tillor account and your permissions in that organisation. Connecting via OAuth requires the permission **Authorize OAuth apps** (`oauth:consent`) in at least one organisation. Without that permission, consent fails and existing OAuth tokens stop working.

## Authentication [#authenticatie]

1. The tool connects to `https://mcp.tillor.dev` without a token
2. OAuth discovery and registration run on the MCP host; login and consent happen on Tillor
3. You approve access in the browser
4. The tool then sends a Bearer token with MCP calls

Send your organisation as a header when the tool supports it (Cursor, Gemini CLI):

```http
X-Tillor-Org-Id: org_abc123
```

Without that header (ChatGPT, Gemini app, Claude) you pass `organizationId` to `call_api_endpoint`. Organisation routes live under `/orgs/{organizationId}`; the API then fills in the header itself.

<Callout type="info" title="No API key needed">
For the hosted MCP server you use OAuth (Connect / Authorize in the tool). For scripts and your own integrations you keep using [API keys](/ontwikkelaars/http).
</Callout>

## Connecting [#koppelen]

Choose your tool:

<McpProviderGuide />

Or open the [install picker](https://install.apicommons.org/?config=eyJuYW1lIjoiVGlsbG9yIiwiZGVzY3JpcHRpb24iOiJUaWxsb3IgUkVTVCBBUEkgdmlhIE9BdXRoIiwicmVtb3RlIjp7InR5cGUiOiJodHRwIiwidXJsIjoiaHR0cHM6Ly9tY3AudGlsbG9yLmRldi9tY3AiLCJoZWFkZXJzIjp7IlgtVGlsbG9yLU9yZy1JZCI6Ijxvcmdhbml6YXRpb25JZD4ifX19) for Cline, Zed, Warp, Codex and the rest.

## Tools [#tools]

| Tool | Purpose |
|------|------|
| `list_api_categories` | Lists API categories |
| `list_api_endpoints` | Endpoints in a category, with input schema |
| `get_api_endpoint_schema` | Schema of a single endpoint by name |
| `call_api_endpoint` | Calls an endpoint |

Endpoint names are not separate tools: use `call_api_endpoint`.

The full REST reference remains [OpenAPI](https://tillor.eu/api/openapi.json). MCP is a layer on top of it, not a separate product API.

## Related [#gerelateerd]

- [HTTP API](/ontwikkelaars/http) - API keys, headers and base URL
- [OpenAPI](https://tillor.eu/api/openapi.json) - Full API specification
- [API reference](/api-referentie) - Every endpoint, to try out in the browser


# Mollie metadata (/en-GB/ontwikkelaars/mollie-metadata)

Mollie stores metadata with every payment. Tillor reads and writes fields in the `tillor` namespace. Link in the app: [Mollie](/boekhouden/betalingsrapporten/betaalmethodes/mollie).

Three kinds:

1. **Link metadata** - Tillor writes back to Mollie so the payment can be recognised
2. **Ingestion hints** - you set them when creating the Mollie payment
3. **Direct bookkeeping metadata** - bypasses Tillor and goes straight to the bookkeeping

## Link metadata [#koppelingsmetadata]

```json
{
  "tillor": {
    "paymentId": "clx123...",
    "invoiceId": "clx456...",
    "customerId": "clx789...",
    "paymentGroupId": "clxgrp..."
  }
}
```

Tillor writes `paymentId`, `invoiceId`, `customerId` and `paymentGroupId` to Mollie as soon as a payment is attached to an invoice, a customer or a [payment group](/betalingsverwerking/groepen). Existing non-Tillor metadata is left in place.

| Field | Description |
|------|---------------|
| `paymentId` | Tillor payment |
| `invoiceId` | Tillor invoice |
| `customerId` | Tillor customer |
| `paymentGroupId` | Payment group, even if that group is not yet attached to an invoice |

## Ingestion hint: `descriptionSuffix` [#ingestie-hint-descriptionsuffix]

You set this yourself when creating the Mollie payment. Tillor uses it for the payment description as soon as there is an invoice link.

```json
{
  "tillor": {
    "descriptionSuffix": "Parkeerplaats P1"
  }
}
```

Format in Tillor: `INV/XXXX/XXXX - {suffix}`.

## Ingestion hints for payment groups [#ingestie-hints-voor-betalingsgroepen]

Handy for POS shifts or activities: bundle several payments before you book an invoice.

```json
{
  "tillor": {
    "paymentGroupName": "Yoga sunrise - Lake Como",
    "paymentGroupExternalId": "act_42"
  }
}
```

One of the two fields is enough. Using both is better if the label may change but the ID stays stable.

| Field | Description |
|------|---------------|
| `paymentGroupName` | Visible label in Tillor. Matches existing open groups by name, or becomes the label of a new group |
| `paymentGroupExternalId` | Stable key from your system. Matches on this instead of on name; the label follows `paymentGroupName` |

1. Tillor looks for an **open** group with this external ID (or, without an ID, with this name).
2. No match? A new open group is created. Its name is `paymentGroupName`, otherwise `paymentGroupExternalId`.
3. The payment joins the group as soon as it is **paid** in Tillor.
4. Groups that are already attached to an invoice are not reused.

Were the hints not yet on the Mollie payment when Tillor first saw the payment? The group is still filled once the payment is **paid**, is **not** attached to an invoice and is **not yet** in a group. This happens at the next synchronisation or on an incoming Mollie notification.

<Callout type="info" title="When to use?">
Pre-tag every Mollie payment from your POS. The group appears under *Administration > Payments*, section *Payment groups*.
</Callout>

<Callout type="warn" title="Do not combine with invoiceId">
A grouped payment cannot be attached to an invoice on its own. If you send both group hints and `invoiceId`, the group wins.
</Callout>

## Direct bookkeeping metadata (`tillor.bookkeeping`) [#directe-boekhoudmetadata-tillorbookkeeping]

Unknown Mollie payments go to suspense account **499000** by default. With `tillor.bookkeeping`, Tillor books them to the specified customer:

```json
{
  "tillor": {
    "bookkeeping": {
      "customerCode": "100001",
      "documentType": "INV",
      "department": "a",
      "fiscalYear": "2026",
      "documentNumber": "00042"
    }
  }
}
```

| Field | Description |
|------|---------------|
| `customerCode` | Customer code in the bookkeeping - required |
| `documentType` | E.g. INV, UF |
| `department` | Department |
| `fiscalYear` | Financial year |
| `documentNumber` | Document number |

If `bookkeeping` is present, the payment does **not** come in as a regular Tillor payment. The metadata is used when building the bookkeeping report.

## See also [#zie-ook]

<Cards>
  <Card title="Mollie (app)" href="/boekhouden/betalingsrapporten/betaalmethodes/mollie" />
  <Card title="Payment groups" href="/betalingsverwerking/groepen" />
  <Card title="Admisol" href="/boekhouden/betalingsrapporten/boekhoudsystemen/admisol" />
</Cards>


# MQTT (/en-GB/ontwikkelaars/mqtt)

MQTT credentials give integrations pub/sub access within your organisation's topic namespace. You create credentials in Tillor under **Account > Developers** (per organisation). Access to topics is limited to `tillor/{env}/{orgId}/integration` and its sub-topics (`{env}` = `prod`, `staging` or `local`), unless a static credential has `topicPrefix: null`.

For the same realtime events as [webhooks](/ontwikkelaars/webhooks) and [SSE](/ontwikkelaars/sse), use those channels, not MQTT.

## Management [#beheer]

| Method | Path | Description |
|--------|------|---------------|
| POST | `/api/orgs/:orgId/mqtt/credentials` | Generate JWT credentials (temporary) |
| GET | `/api/orgs/:orgId/mqtt/static-credentials` | Retrieve static credentials |
| POST | `/api/orgs/:orgId/mqtt/static-credentials` | Create a static credential |
| DELETE | `/api/orgs/:orgId/mqtt/static-credentials/:id` | Delete a static credential |

Authentication: `x-api-key`, with the organisation ID in the path (same as the [HTTP API](/ontwikkelaars/http)). See the [OpenAPI specification](https://tillor.eu/api/openapi.json) for the full request and response schemas.

## Credentials [#credentials]

There are two variants:

### JWT (temporary) [#jwt-tijdelijk]

- **Use:** Short sessions, temporary access
- **Expiry:** 1 hour by default; configurable from 1 minute to 24 hours via `expiresInSeconds`
- **Ideal for:** Testing, temporary connections, or when you fetch tokens dynamically
- **Creating:** In Tillor under **Account > Developers**, or via `POST /api/orgs/:orgId/mqtt/credentials` with optionally `{ "clientId": "...", "expiresInSeconds": 3600 }`
- **Response:** `token` (use as MQTT password), `clientId`, `brokerUrl`, `topicPrefix`, `expiresAt`
- **Username:** Leave empty when connecting; JWT authentication only uses the token as password.
- **Client ID:** Use exactly the `clientId` from the response when connecting (including the environment prefix, e.g. `prod-`).

A connection to the broker via **mqtts** verifies the server certificate. If you use a **private** CA certificate (not the standard public chain), put the PEM of that CA in your client environment.

### Static credentials [#statische-credentials]

- **Use:** Long-running integrations, always-on connections
- **Form:** Fixed userName, clientId and password
- **Ideal for:** Production integrations that stay connected continuously
- **Creating:** In Tillor under **Account > Developers**, or via `POST /api/orgs/:orgId/mqtt/static-credentials` with optionally `{ "name": "mijn-integratie", "topicPrefix": null }`
- **Response:** `userName`, `clientId`, `password` (once only), `topicPrefix` (`null` = no prefix, ACL `#`), optionally `brokerUrl`
- **Note:** The password is shown once in the response and cannot be retrieved afterwards

---

## Topic access [#topic-toegang]

Topic subscriptions are **strictly limited**, unless `topicPrefix` is `null` (ACL `#`). By default you can only publish and subscribe on `tillor/{env}/{orgId}/integration` and `tillor/{env}/{orgId}/integration/#`.

- **Allowed topics** - Only `tillor/{env}/{orgId}/integration` and sub-topics (e.g. `tillor/{env}/{orgId}/integration/connector/access-point-operation`)
- **No wildcard bypass** - Even with `#` or `+` you only get access to your organisation namespace
- **Per organisation** - Credentials are per organisation; you have no access to topics of other organisations

---

## Related [#gerelateerd]

- [OpenAPI](https://tillor.eu/api/openapi.json) - Full API specification
- [HTTP API](/ontwikkelaars/http) - REST API and API keys
- [Webhooks](/ontwikkelaars/webhooks) - Same events via HTTP POST
- [SSE](/ontwikkelaars/sse) - Stream events via Server-Sent Events


# OAuth-clients (/en-GB/ontwikkelaars/oauth-clients)

Met een OAuth-client meldt een andere applicatie mensen aan met hun Tillor-account. Tillor is daarbij de OpenID Connect-provider: de applicatie stuurt de gebruiker naar Tillor, de gebruiker meldt zich aan en geeft toestemming, en de applicatie krijgt te horen wie het is. Je gebruikt dat voor een eigen applicatie, of voor single sign-on bij een externe dienst die aanmelden via een eigen identiteitsprovider ondersteunt.

Standaard kan elk Tillor-account zich via een client aanmelden. Voor single sign-on bij een externe dienst wil je dat bijna nooit: beperk de client dan tot mensen van je organisatie.

## Wat je nodig hebt [#wat-je-nodig-hebt]

- De **redirect-URI** die de applicatie of dienst opgeeft.
- Wie zich aanmeldt, heeft het recht **OAuth-apps autoriseren** nodig. Zie [OAuth-apps](/gebruikers/organisaties#oauth-apps).
- Om een client tot je organisatie te beperken: het recht **Integraties beheren** in die organisatie.

## Een client aanmaken [#een-client-aanmaken]

<Steps>
<Step>

Klik in de sidebar op je naam en kies <UIPath>Account > OAuth-clients</UIPath>. Klik op **OAuth-client aanmaken**.

</Step>
<Step>

Vul de **Applicatienaam** in en zet elke **Redirect-URI** op een eigen regel. Vink **Publieke client** alleen aan voor een applicatie die geen geheim kan bewaren, zoals een mobiele app.

</Step>
<Step>

Kies wie zich mag aanmelden. Zie [Beperken wie zich mag aanmelden](#beperken-wie-zich-mag-aanmelden).

</Step>
<Step>

Sla op. Tillor toont de **Client-ID** en het **Clientgeheim**. Het geheim zie je alleen nu: kopieer het en bewaar het veilig.

</Step>
</Steps>

In de applicatie of dienst vul je de client-ID, het clientgeheim en het adres van Tillor als provider in: `https://tillor.eu/api/auth`. De meeste diensten lezen de rest zelf uit `https://tillor.eu/api/auth/.well-known/openid-configuration`.

## Beperken wie zich mag aanmelden [#beperken-wie-zich-mag-aanmelden]

Vink **Alleen mensen van (je organisatie) kunnen aanmelden** aan in het venster van de client. De beperking geldt voor de organisatie waarin je op dat moment werkt. Daarna kan je ze verder vernauwen:

| Voorwaarde | Wie voldoet |
|---|---|
| Organisatie (altijd) | Wie lid is van de organisatie |
| **Groepen** (nul of meer) | Wie in **minstens één** van de gekozen [groepen](/gebruikers/groepen) zit |
| **Permissies** (nul of meer) | Wie **alle** gekozen rechten heeft in de organisatie, met de rechten uit groepen meegerekend |

De voorwaarden gelden samen: iemand moet lid zijn, **en** in een van de groepen zitten, **en** alle rechten hebben. Een lege lijst groepen of permissies telt niet mee. Kies je dus geen groepen en geen permissies, dan mag elk lid van de organisatie zich aanmelden.

Een voorbeeld: je kiest de groep "Boekhouding" en het recht om betalingen te bekijken. Alleen wie lid is van je organisatie, in "Boekhouding" zit en betalingen mag bekijken, komt binnen.

De kolom **Wie kan aanmelden** in de lijst van clients toont de beperking van elke client.

<Callout type="info" title="Goed om te weten">
- Kies bij voorkeur **groepen**. Een groep is van jou: je bepaalt zelf wie erin zit. De betekenis van een recht kan in een latere versie van Tillor veranderen, en dan verandert mee wie zich bij de externe dienst kan aanmelden.
- Tillor controleert de voorwaarden bij elke aanmelding en telkens wanneer de applicatie de sessie vernieuwt. Wie de organisatie of de groep verlaat of een recht verliest, krijgt geen nieuwe toegang meer. Toegang die al was uitgereikt, vervalt binnen het uur.
- Voor een beheerder van Tillor zelf gelden dezelfde voorwaarden. Zo iemand is lid van elke organisatie: kies een groep als alleen je eigen mensen binnen mogen.
- Je wijzigt of verwijdert de beperking vanuit de organisatie waarvoor ze geldt. Werk je in een andere organisatie, dan toont het venster alleen voor welke organisatie de client beperkt is.
- Elke wijziging van de beperking en elke geweigerde aanmelding staat in de [activiteitenlog](/activiteitenlog) van de organisatie.
</Callout>

## Problemen? [#problemen]

**Iemand krijgt bij de externe dienst de fout `access_denied`.**
Die persoon voldoet niet aan de voorwaarden van de client. Kijk in de activiteitenlog naar de regel **Toegang geweigerd**: de reden zegt of het om het lidmaatschap, de groep of een recht gaat.

**Iemand ziet op het toestemmingsscherm "Niet beschikbaar voor uw account".**
Zelfde oorzaak: de client is beperkt en dit account voldoet niet. Voeg de persoon toe aan de juiste groep of geef het ontbrekende recht.

**Bij een groep staat "Verwijderde groep".**
De groep bestaat niet meer, en niemand kan er nog in zitten. Was het de enige gekozen groep, dan kan niemand zich aanmelden. Vink ze uit of kies een andere groep.

**Het vakje om te beperken is grijs.**
Je mist het recht **Integraties beheren** in deze organisatie. Vraag het aan een beheerder.

**Na het verlies van een recht blijft iemand nog even aangemeld bij de externe dienst.**
De externe dienst houdt zijn eigen sessie bij. Tillor weigert de volgende vernieuwing; hoe snel de dienst de persoon afmeldt, hangt van die dienst af.


# Server-Sent Events (SSE) (/en-GB/ontwikkelaars/sse)

SSE offers a long-running stream of the same events that [webhooks](/ontwikkelaars/webhooks) receive. Use SSE when you prefer a persistent connection over HTTP callbacks.

## Endpoint [#endpoint]

```
GET /api/orgs/:orgId/realtime/subscribe
```

## Authentication [#authenticatie]

SSE uses the same authentication as other API endpoints:

- **x-api-key** - Your API key

The organisation ID is in the URL path.

## Event filtering [#event-filtering]

Use the `events` query parameter to filter by event type:

```
GET /api/orgs/:orgId/realtime/subscribe?events=invoice:created&events=invoice:paid
```

Use `events=*` to receive all events (same as omitting the parameter).

See the [Event index](/ontwikkelaars/events) for all events, the permission per event and an example payload.

A few events have their own channel (controller logs and controller I/O). You only receive those with `?channel=controller-logs` or `?channel=controller-io`; the Event index states the channel.

Tillor only delivers events for which the signed-in organisation member has permission. Without `bank-transactions:read` (or sync), for example, you do not get `bankAccountTransaction:*` events, not even if you send no `events` filter.

Linked data from another domain follows the same rules as the API: without `customers:read`, a `reservation:updated` arrives with `customer: null`, and without `payments:read` an `invoice:paid` arrives with `payment: null`. A list then becomes `[]`.

---

## Event format [#event-formaat]

The payload has the same structure as [webhook deliveries](/ontwikkelaars/webhooks#webhook-payload):

| Field | Type | Description |
|------|------|--------------|
| `event` | string | Event key (e.g. `invoice:created`) |
| `data` | object | Event-specific payload |
| `timestamp` | number | Unix timestamp (ms) when the event was emitted |
| `traceId` | string | OpenTelemetry trace ID of the Tillor action that caused this event (same as with [webhooks](/ontwikkelaars/webhooks#webhook-payload)) |
| `spanId` | string (optional) | Span within that trace |

In the SSE stream this JSON object is on the `data:` line; the event key is also on the `event:` line. See [SSE examples](/ontwikkelaars/voorbeelden/sse) for a wire example.

---

## Example: Node.js [#voorbeeld-nodejs]

```javascript
const orgId = "org_abc123";
const apiKey = "tkn_xxx";

const url = `https://app.tillor.eu/api/orgs/${orgId}/realtime/subscribe?events=invoice:created&events=customer:updated`;

const response = await fetch(url, {
  headers: {
    "x-api-key": apiKey,
    "Accept": "text/event-stream",
  },
});

const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  const chunk = decoder.decode(value, { stream: true });
  for (const line of chunk.split("\n")) {
    if (line.startsWith("data: ")) {
      const payload = JSON.parse(line.slice(6));
      console.log(payload.event, payload.data);
    }
  }
}
```

---

## Example: cURL [#voorbeeld-curl]

```bash
curl -N -H "x-api-key: tkn_xxx" \
     -H "Accept: text/event-stream" \
     "https://app.tillor.eu/api/orgs/org_abc123/realtime/subscribe"
```

---

## Reconnecting [#herverbinding]

If the connection drops, reconnect with the same URL and headers. The stream does not support resumption; you only receive new events after reconnecting.

---

## Related [#gerelateerd]

- [OpenAPI](https://tillor.eu/api/openapi.json) - Full API specification
- [HTTP API](/ontwikkelaars/http) - API keys and authentication
- [Webhooks](/ontwikkelaars/webhooks) - Same events via HTTP POST
- [Examples](/ontwikkelaars/voorbeelden) - Code and payload examples


# HTTP examples (/en-GB/ontwikkelaars/voorbeelden/http)

Opening hours and public holidays for a public site: [Opening hours API](/ontwikkelaars/voorbeelden/opening-hours).

## API request with cURL [#api-request-met-curl]

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/customers" \
  -H "x-api-key: tkn_xxx" \
  -H "Content-Type: application/json"
```

## Creating an API key [#api-sleutel-aanmaken]

```bash
curl -X POST "https://tillor.eu/api/api-keys" \
  -H "Cookie: session=..." \
  -H "Content-Type: application/json" \
  -d '{"name": "Mijn integratie", "description": "Optionele beschrijving"}'
```

## Creating a webhook [#webhook-aanmaken]

```bash
curl -X POST "https://tillor.eu/api/orgs/org_abc123/webhooks" \
  -H "x-api-key: tkn_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://jouw-server.com/webhooks/tillor",
    "subscribedEventKeys": ["invoice:created", "invoice:paid", "customer:updated"],
    "enabled": true
  }'
```


# Overview (/en-GB/ontwikkelaars/voorbeelden)

Ready-made examples to get you started. Every example uses the placeholders `org_abc123` and `tkn_xxx`; replace them with your own organisation ID and API key.

<Cards>
  <Card
    title="HTTP examples"
    href="/ontwikkelaars/voorbeelden/http"
    description="cURL and request examples for the Tillor API"
  />
  <Card
    title="Opening hours API"
    href="/ontwikkelaars/voorbeelden/opening-hours"
    description="Fetch resolved opening hours and upcoming public holidays for a website"
  />
  <Card
    title="Webhook examples"
    href="/ontwikkelaars/voorbeelden/webhooks"
    description="Event payloads and webhook POST examples"
  />
  <Card
    title="SSE examples"
    href="/ontwikkelaars/voorbeelden/sse"
    description="Node.js and cURL for Server-Sent Events"
  />
</Cards>


# Opening hours API (/en-GB/ontwikkelaars/voorbeelden/opening-hours)

Use the **resolved** opening hours API if you show seasonal hours (for example **Summer** / **Winter**) or upcoming **public holidays** on a public site. Tillor already applies exceptions, seasonal periods and the regular weekly schedule, and adds statutory public holidays in the requested range. You do not have to implement that again.

**Permission:** `organization:settings:read` or `organization:settings:write`

<Callout type="warn" title="Keep the API key server-side">
Only call Tillor from a server (Next.js Route Handler, Server Component or backend). Put the key in environment variables. Never send it to the browser.
</Callout>

Authentication: see [HTTP API](/ontwikkelaars/http). Try the endpoint in the [API reference](/api-referentie) or via [OpenAPI](https://tillor.eu/api/openapi.json) (tag `organization-settings`).

## Endpoint [#endpoint]

```
GET https://tillor.eu/api/orgs/org_abc123/organization-settings/opening-hours
```

Headers:

```http
x-api-key: tkn_xxx
```

Replace `org_abc123` with your organisation ID.

### Query parameters [#queryparameters]

Use **either** `date` **or** `from`/`to`. Do not combine them.

| Parameter | Meaning |
|-----------|-----------|
| *(none)* | Today in the organisation's timezone |
| `date` | A single calendar day (`YYYY-MM-DD`) |
| `from` | Start day (inclusive). Without `to`: only that day |
| `to` | End day (inclusive). Requires `from`. Maximum **366** days |
| `languageIsoCode` | Language for public holiday names (`NL`, `FR`, …). Default: locale of the organisation |

## Response [#response]

Each item is one calendar day, already resolved:

| Field | Meaning |
|------|-----------|
| `timeZone` | IANA timezone of the organisation |
| `from` / `to` | Requested range |
| `holidays` | Statutory public holidays that overlap with `from`–`to` |
| `items[].date` | Calendar day `YYYY-MM-DD` |
| `items[].weekday` | `monday` … `sunday` |
| `items[].source` | `exception`, `period` or `regular` |
| `items[].periodLabel` | Only with `source: "period"`: the label from Tillor, for example `"Zomer"` or `"Winter"` |
| `items[].holiday` | Only if that day is a statutory public holiday: `{ id, name, startDate, endDate }` |
| `items[].blocks` | Time slots in minutes from midnight |
| `items[].closed` | `true` if `blocks` is empty |

Priority: **exception** (public holiday or custom range) → last matching **seasonal period** → **regular** weekly schedule.

Season labels come from *Settings > Opening hours*. Periods may run across the turn of the year (for example 1 November to 31 March). Days outside every period fall back to the regular weekly schedule (`source: "regular"`, no `periodLabel`).

### Minutes to clock time [#minuten-naar-kloktijd]

`startMinutes` / `endMinutes` are minutes from 00:00.

| Minutes | Time |
|--------:|------|
| 540 | 09:00 |
| 600 | 10:00 |
| 720 | 12:00 |
| 780 | 13:00 |
| 1020 | 17:00 |
| 1140 | 19:00 |

```ts
function formatMinutes(minutes: number): string {
  const hour = Math.floor(minutes / 60);
  const minute = minutes % 60;
  return `${String(hour).padStart(2, "0")}:${String(minute).padStart(2, "0")}`;
}
```

## Examples [#voorbeelden]

### A day in a seasonal period [#dag-in-een-seizoensperiode]

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/organization-settings/opening-hours?date=2026-07-15" \
  -H "x-api-key: tkn_xxx"
```

```json
{
  "timeZone": "Europe/Brussels",
  "from": "2026-07-15",
  "to": "2026-07-15",
  "holidays": [],
  "items": [
    {
      "date": "2026-07-15",
      "weekday": "wednesday",
      "source": "period",
      "periodLabel": "Zomer",
      "blocks": [{ "startMinutes": 540, "endMinutes": 720 }],
      "closed": false
    }
  ]
}
```

09:00–12:00, summer hours.

### A day outside seasonal periods [#dag-buiten-seizoensperiodes]

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/organization-settings/opening-hours?date=2026-01-15" \
  -H "x-api-key: tkn_xxx"
```

```json
{
  "timeZone": "Europe/Brussels",
  "from": "2026-01-15",
  "to": "2026-01-15",
  "holidays": [],
  "items": [
    {
      "date": "2026-01-15",
      "weekday": "thursday",
      "source": "regular",
      "blocks": [
        { "startMinutes": 540, "endMinutes": 720 },
        { "startMinutes": 780, "endMinutes": 1020 }
      ],
      "closed": false
    }
  ]
}
```

09:00–12:00 and 13:00–17:00.

### A range across a period boundary [#range-over-een-periodegrens]

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/organization-settings/opening-hours?from=2026-03-30&to=2026-04-02" \
  -H "x-api-key: tkn_xxx"
```

| Date | `source` | `periodLabel` |
|-------|----------|---------------|
| 2026-03-30 | `regular` | - |
| 2026-03-31 | `regular` | - |
| 2026-04-01 | `period` | `Zomer` |
| 2026-04-02 | `period` | `Zomer` |

## Upcoming public holidays [#komende-feestdagen]

Statutory public holidays are in the same response: `holidays` for a list (name + dates), `items[].holiday` if that calendar day is a public holiday. Hours remain the resolved schedule; a public holiday without a filled-in exception in Tillor follows the seasonal or weekly schedule (`source` is then not `"exception"`).

```bash
curl -X GET "https://tillor.eu/api/orgs/org_abc123/organization-settings/opening-hours?from=2026-08-27&to=2026-12-31&languageIsoCode=NL" \
  -H "x-api-key: tkn_xxx"
```

```json
{
  "timeZone": "Europe/Brussels",
  "from": "2026-08-27",
  "to": "2026-12-31",
  "holidays": [
    {
      "id": "0fad0035-6b77-404a-953d-c66dac014483",
      "name": "Allerheiligen",
      "startDate": "2026-11-01",
      "endDate": "2026-11-01"
    },
    {
      "id": "d90e5f53-bc92-4860-bdae-f7e75935848d",
      "name": "Kerstmis",
      "startDate": "2026-12-25",
      "endDate": "2026-12-25"
    }
  ],
  "items": [
    {
      "date": "2026-11-01",
      "weekday": "sunday",
      "source": "regular",
      "holiday": {
        "id": "0fad0035-6b77-404a-953d-c66dac014483",
        "name": "Allerheiligen",
        "startDate": "2026-11-01",
        "endDate": "2026-11-01"
      },
      "blocks": [],
      "closed": true
    }
  ]
}
```

The `items` example above is shortened; the real response contains every day in the range. School holidays are not in this endpoint; they remain `GET /holidays?kind=school`.

## Next.js (server) [#nextjs-server]

For a week widget or “open now” on a public site:

```ts
const TILLOR_API_URL = "https://tillor.eu";
const ORGANIZATION_ID = process.env.TILLOR_ORG_ID ?? "";

type OpeningHoursBlock = {
  startMinutes: number;
  endMinutes: number;
};

type OpeningHoursHoliday = {
  id: string;
  name: string;
  startDate: string;
  endDate: string;
};

type OpeningHoursItem = {
  date: string;
  weekday: string;
  source: "exception" | "period" | "regular";
  periodLabel?: string;
  holiday?: OpeningHoursHoliday;
  blocks: OpeningHoursBlock[];
  closed: boolean;
};

type OpeningHoursResponse = {
  timeZone: string;
  from: string;
  to: string;
  holidays: OpeningHoursHoliday[];
  items: OpeningHoursItem[];
};

export async function getOpeningHours(
  from: string,
  to: string,
): Promise<OpeningHoursResponse> {
  const url = new URL(
    `${TILLOR_API_URL}/api/orgs/${ORGANIZATION_ID}/organization-settings/opening-hours`,
  );
  url.searchParams.set("from", from);
  url.searchParams.set("to", to);
  url.searchParams.set("languageIsoCode", "NL");

  const response = await fetch(url, {
    headers: {
      "x-api-key": process.env.TILLOR_API_KEY ?? "",
    },
    next: { tags: ["opening-hours"], revalidate: 3600 },
  });

  if (!response.ok) {
    throw new Error(`Tillor opening hours ${response.status}`);
  }

  return response.json() as Promise<OpeningHoursResponse>;
}
```

`holidays` is the list for an “upcoming public holidays” block. `items[].holiday` is handy in a week calendar. `items[].periodLabel` is season text (for example `"Zomer"` or `"Winter"`). A one-hour cache is usually enough.

## Invalidating the cache (webhook) [#cache-ongeldig-maken-webhook]

On every change to organisation settings, Tillor sends `organizationSettings:updated` (webhook and SSE). Subscribe to it and fetch the opening hours again. The payload is deliberately small (no printer IPs or the full schedule):

```json
{
  "event": "organizationSettings:updated",
  "data": {
    "openingHoursChanged": true
  },
  "timestamp": 1787829600000
}
```

`openingHoursChanged` is `true` if the opening hours schedule, the timezone or the default country changes - that is what affects `GET .../opening-hours`. With `false` you can leave the opening hours cache in place.

Next.js Route Handler example:

```ts
import { revalidateTag } from "next/cache";

export async function POST(request: Request) {
  const body = (await request.json()) as {
    event?: string;
    data?: { openingHoursChanged?: boolean };
  };
  if (body.event === "organizationSettings:updated" && body.data?.openingHoursChanged) {
    await revalidateTag("opening-hours");
  }
  return new Response(null, { status: 204 });
}
```

Creating a webhook: see [Webhooks](/ontwikkelaars/webhooks). Event key: `organizationSettings:updated` (permission `organization:settings:read` or `organization:settings:write`).

## Full schedule (optional) [#volledig-rooster-optioneel]

Only needed if you want to show the season calendar yourself (labels + `fromMonth`/`untilDay`), without resolving per day:

```
GET https://tillor.eu/api/orgs/org_abc123/organization-settings
```

Read `openingHoursSchedule.periods` (labels such as `"Zomer"`) and `openingHoursSchedule.weekdays` (regular schedule). For the website itself, `GET .../opening-hours` remains the simplest source.

## MCP [#mcp]

In Cursor or Claude: endpoint `organizationSettings_listOpeningHours` (category `organizationSettings`), arguments `organizationId`, optionally `date` or `from`/`to`, optionally `languageIsoCode`.

## Related [#gerelateerd]

- [HTTP API](/ontwikkelaars/http) - authentication and headers
- [HTTP examples](/ontwikkelaars/voorbeelden/http) - general cURL examples
- [Webhooks](/ontwikkelaars/webhooks) - `organizationSettings:updated` for cache revalidation
- [Organization settings](/gebruikers/organisaties) - setting up opening hours in Tillor


# SSE examples (/en-GB/ontwikkelaars/voorbeelden/sse)

## cURL [#curl]

```bash
curl -N -H "x-api-key: tkn_xxx" \
     "https://app.tillor.eu/api/orgs/org_abc123/realtime/subscribe"
```

## Node.js [#nodejs]

```javascript
const orgId = "org_abc123";
const apiKey = "tkn_xxx";

const url = `https://app.tillor.eu/api/orgs/${orgId}/realtime/subscribe?events=invoice:created&events=customer:updated`;

const response = await fetch(url, {
  headers: {
    "x-api-key": apiKey,
    "Accept": "text/event-stream",
  },
});

const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  const chunk = decoder.decode(value, { stream: true });
  for (const line of chunk.split("\n")) {
    if (line.startsWith("data: ")) {
      const payload = JSON.parse(line.slice(6));
      console.log(payload.event, payload.data);
    }
  }
}
```

## SSE message [#sse-bericht]

An SSE message (`text/event-stream`) looks like this:

```
event: message
data: {"event":"invoice:paid","data":{"invoice":{"id":"inv_def456uvw","displayId":"2025-00123","status":"BOOKED","paymentStatus":"PAID","amountTotal":200,"paidDate":"2025-03-09T12:15:00.000Z","customerId":"cust_abc123xyz"},"payment":{"id":"pay_ghi789rst","amount":200,"status":"PAID","method":"BANCONTACT","provider":"MOLLIE","paidAt":"2025-03-09T12:15:00.000Z"}},"timestamp":1735811700000}

```

The SSE `event` line is `message`. Parse the `data` line as JSON: it contains the Tillor event (`event`), the payload (`data`) and `timestamp` (ms). You receive the same JSON object via [webhooks](/ontwikkelaars/webhooks).


# Webhook examples (/en-GB/ontwikkelaars/voorbeelden/webhooks)

The same events as with [SSE](/ontwikkelaars/voorbeelden/sse). The payload structure is identical.

## Wrapper structure [#wrapper-structuur]

```json
{
  "event": "entity:action",
  "data": {},
  "timestamp": 1735689600000,
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7"
}
```

`traceId` belongs to the Tillor action that caused the event (e.g. an API call or internal processing), not to a later webhook retry.

## Webhook POST example [#webhook-post-voorbeeld]

A complete webhook POST request looks like this:

```http
POST /webhooks/tillor HTTP/1.1
Host: your-server.com
Content-Type: application/json

{
  "event": "invoice:paid",
  "data": {
    "invoice": {
      "id": "inv_def456uvw",
      "displayId": "2025-00123",
      "status": "BOOKED",
      "paymentStatus": "PAID",
      "amountTotal": 200.0,
      "paidDate": "2025-03-09T12:15:00.000Z",
      "customerId": "cust_abc123xyz"
    },
    "payment": {
      "id": "pay_ghi789rst",
      "amount": 200.0,
      "status": "PAID",
      "method": "BANCONTACT",
      "channel": "ONLINE",
      "provider": "MOLLIE",
      "paidAt": "2025-03-09T12:15:00.000Z"
    }
  },
  "timestamp": 1735811700000,
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7"
}
```

## Event payloads [#event-payloads]

### customer:created [#customercreated]

```json
{
  "event": "customer:created",
  "data": {
    "id": "cust_abc123xyz",
    "displayId": 1042,
    "firstName": "Jan",
    "lastName": "Jansen",
    "email": "jan.jansen@voorbeeld.nl",
    "phone": "+31612345678",
    "address": "Hoofdstraat 42",
    "city": "Amsterdam",
    "zipCode": "1012 AB",
    "country": "NL",
    "customerType": "STANDARD",
    "status": "DEFAULT",
    "createdAt": "2025-03-09T10:30:00.000Z",
    "updatedAt": "2025-03-09T10:30:00.000Z"
  },
  "timestamp": 1735806600000
}
```

### invoice:paid [#invoicepaid]

```json
{
  "event": "invoice:paid",
  "data": {
    "invoice": {
      "id": "inv_def456uvw",
      "displayId": "2025-00123",
      "status": "BOOKED",
      "paymentStatus": "PAID",
      "amountTotal": 200.0,
      "paidDate": "2025-03-09T12:15:00.000Z",
      "customerId": "cust_abc123xyz"
    },
    "payment": {
      "id": "pay_ghi789rst",
      "amount": 200.0,
      "status": "PAID",
      "method": "BANCONTACT",
      "channel": "ONLINE",
      "provider": "MOLLIE",
      "paidAt": "2025-03-09T12:15:00.000Z"
    }
  },
  "timestamp": 1735811700000
}
```

### controller:adoption:requested [#controlleradoptionrequested]

```json
{
  "event": "controller:adoption:requested",
  "data": {
    "adoptionId": "adopt_jkl012mno",
    "efuseId": "a1b2c3d4e5f6",
    "requestedFromIp": "192.168.1.42",
    "isNew": true
  },
  "timestamp": 1735809000000
}
```

### nfc-tag:presented [#nfc-tagpresented]

```json
{
  "event": "nfc-tag:presented",
  "data": {
    "id": "nfc_123abc456",
    "uid": "04A1B2C3D4E5F6",
    "type": "CARD",
    "balance": 25.5,
    "blockedAt": null,
    "customerId": "cust_abc123xyz"
  },
  "timestamp": 1735807500000
}
```

### organizationSettings:updated [#organizationsettingsupdated]

```json
{
  "event": "organizationSettings:updated",
  "data": {
    "openingHoursChanged": true
  },
  "timestamp": 1787829600000
}
```

See [Opening hours API](/ontwikkelaars/voorbeelden/opening-hours) for cache revalidation on a public site.

## Enums [#enums]

| Entity | Enum | Values |
|--------|------|---------|
| Customer | `customerType` | `STANDARD`, `WORKER_RENTAL_CARAVAN`, `WORKER_TOWING_CARAVAN` |
| Invoice | `status` | `DRAFT`, `BOOKED` |
| Invoice | `paymentStatus` | `UNPAID`, `PARTIALLY_PAID`, `PENDING`, `PAID` |
| Payment | `status` | `PENDING`, `AUTHORIZED`, `PAID`, `CANCELED`, `FAILED`, `EXPIRED`, `REFUNDED`, `PARTIALLY_REFUNDED`, `REFUND_PENDING`, `PARTIAL_REFUND_PENDING`, `CHARGED_BACK` |
| Payment | `method` | `UNKNOWN`, `BANCONTACT`, `IDEAL`, `CREDITCARD`, `CASH`, … (full list in OpenAPI) |
| Payment | `channel` | `MANUAL`, `BANK_TRANSFER`, `TERMINAL`, `ONLINE`, `MANDATE` |
| Payment | `provider` | `MOLLIE`, `MANUAL`, `PONTO` |
| Controller | `type` | `ACCESS`, `SHOWER`, `CHARGE_POINT` |
| NfcTag | `type` | `CARD`, `BRACELET`, `STICKER`, `KEY_FOB` |


# Webhooks (/en-GB/ontwikkelaars/webhooks)

Webhooks receive realtime events via HTTP POST to a URL you configure. The same events are also available via [SSE](/ontwikkelaars/sse). Webhooks are configured **per organisation** - every organisation has its own webhooks.

## Management [#beheer]

See the [OpenAPI specification](https://tillor.eu/api/openapi.json) for the full request and response schemas.

| Method | Path | Description |
|--------|------|-------------|
| GET | `/api/orgs/:orgId/webhooks` | Retrieve webhooks |
| GET | `/api/orgs/:orgId/webhooks/delivery-stats` | Retrieve delivery statistics |
| POST | `/api/orgs/:orgId/webhooks/retry-deliveries` | Retry deliveries. Body: `mode` (`failed` or `force`) and optionally `id` for a single webhook. `failed`: only permanently failed deliveries, immediately. `force`: pending and permanently failed deliveries in the background, ignoring wait times. |
| GET | `/api/orgs/:orgId/webhooks/:id` | Retrieve a webhook by ID |
| POST | `/api/orgs/:orgId/webhooks` | Create a webhook |
| PATCH | `/api/orgs/:orgId/webhooks/:id` | Update a webhook |
| DELETE | `/api/orgs/:orgId/webhooks/:id` | Delete a webhook |

## Creating a webhook [#webhook-aanmaken]

```http
POST /api/orgs/org_abc123/webhooks
Content-Type: application/json
x-api-key: tkn_xxx
```

```json
{
  "url": "https://jouw-server.com/webhooks/tillor",
  "subscribedEventKeys": ["invoice:created", "invoice:paid", "customer:updated"],
  "enabled": true
}
```

- **url** - HTTPS endpoint that accepts POST requests
- **subscribedEventKeys** - Array of event keys or `["*"]` for all events. The full list is in Tillor under **Profile menu → Developers**, at **Add webhook** → **Subscribed events**.

A few events occur so often that you cannot choose them and they do not arrive via `*` either, such as the physical state of barriers, typing in the inbox, controller logs and vehicle presence. They are not in the list below. Which events you can choose also depends on your permissions.
- **enabled** - `true` to switch delivery on

You may only choose events for which your organisation member has the right permission (e.g. bank transactions for `bankAccountTransaction:*`). Wildcard `*` is only available to members with full access (`*`). With an invalid combination the API returns an error. A webhook forwards the full payload, including the linked data (such as the customer on a reservation). That is why you must also be allowed to read those domains in order to create a webhook, change its URL or events, or switch it back on.

---

## Webhook payload [#webhook-payload]

Every webhook delivery is a POST with:

**Headers:**
- `Content-Type: application/json`
- `X-Webhook-Event-ID` - stable unique ID for this logical delivery (same value on retries)
- `X-Webhook-Signature` - HMAC-SHA256 signature of the body, format `sha256=<hex>` (see [Verifying the signature](#handtekening-verifiëren))

**Body:**

```json
{
  "event": "invoice:created",
  "data": {},
  "timestamp": 1735689600000,
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7",
  "triggeredBy": {
    "id": "usr_63x8jp68is",
    "name": "Niels"
  }
}
```

| Field | Type | Description |
|------|------|--------------|
| `event` | string | Event key (e.g. `invoice:created`) |
| `data` | object | Event-specific payload |
| `timestamp` | number | Unix timestamp (ms) when the event was emitted |
| `traceId` | string | OpenTelemetry trace ID of the Tillor action that caused this event. Pass it on to support; it is not a secret. |
| `spanId` | string (optional) | Span within that trace |
| `triggeredBy` | object \| null | User who performed the action (`id`, `name`). `null` for system actions (cron, bank sync, …) |

See [Examples](/ontwikkelaars/voorbeelden) for full payload examples.

---

## Verifying the signature [#handtekening-verifiëren]

Every webhook has its own **signing secret** (64 hex characters, visible in the webhook table via **Show signing secret** on *Profile menu → Developers*). Tillor signs every POST with that secret so that you can verify that the request really comes from Tillor and that the body has not been altered.

**How Tillor signs:**

1. Compute `HMAC-SHA256(signingSecret, raw_request_body)` (lowercase hex).
2. Send that as `X-Webhook-Signature: sha256=<hex>`.

**How you verify:**

1. Read the **raw** request body (before JSON parsing - otherwise the hash will not match).
2. Compute `HMAC-SHA256(signingSecret, raw_body)` yourself in hex.
3. Compare it with the value after `sha256=` in the `X-Webhook-Signature` header using a **constant-time** comparison.

```js
import crypto from "node:crypto";

function verifyTillorWebhook(rawBody, headerSignature, signingSecret) {
  const expected = crypto.createHmac("sha256", signingSecret).update(rawBody).digest("hex");
  const received = headerSignature.replace(/^sha256=/, "");
  const a = Buffer.from(expected, "hex");
  const b = Buffer.from(received, "hex");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
```

<Callout type="warn" title="Treat the secret like a password">
You can show the signing secret in Tillor via **Show signing secret** in the webhook table. Store it as a secret (env var, vault) and never log it. Suspect a leak? Delete the webhook and create a new one; that gives you a new secret.
</Callout>

---

## Delivery behaviour and retries [#leveringsgedrag-en-retries]

- Reply with a **2xx status** to confirm success.
- If a delivery fails (non-2xx, network error or blocked target), Tillor automatically retries the delivery with increasingly long intervals. Every attempt reuses the same payload, the same signature and the same event ID (idempotent).

| Attempt | Wait since previous attempt |
|---|---|
| 1 | immediately |
| 2 | 1 second |
| 3 | 2 seconds |
| 4 | 4 seconds |
| 5 | 8 seconds |
| 6 | 5 minutes |
| 7 | 30 minutes |
| 8 | 2 hours |
| 9 | 6 hours |
| 10 | 24 hours |

- If one of the attempts succeeds (2xx) → the delivery is complete.
- If attempt 10 (after 24 h) also fails → the delivery is **permanently marked as failed** and not attempted further.
- If the webhook is **disabled** in the meantime, Tillor stops retrying.

```mermaid
flowchart TD
  A[Event uitgezonden] --> B[Levering naar jouw endpoint]
  B -- 2xx --> Z[Afgerond]
  B -- mislukt --> C[Opnieuw geprobeerd<br/>1s, 2s, 4s, 8s,<br/>5m, 30m, 2u, 6u, 24u]
  C -- 2xx --> Z
  C -- alle pogingen mislukt --> F[Definitief mislukt]
```

<Callout type="info" title="Idempotency">
Every retry reuses the same `X-Webhook-Event-ID` and `X-Webhook-Signature`. Deduplicate on your side on that header so that a successful retry after a slow 200 does not cause double processing.
</Callout>

### Notifications for persistent failures [#meldingen-bij-aanhoudende-fouten]

If deliveries for a webhook endpoint keep failing, Tillor sends **at most two notifications per incident** (per endpoint):

1. **After 5 minutes of persistent failures** - email to the organisation email address (`supportEmail`, otherwise `email`) and to organisation members with permission to change organisation settings, plus push (if enabled) for those members. The email states since when the deliveries have been failing. Dates in the email use the **time zone** from *Settings > General* (default `Europe/Brussels`).
2. **On permanent failure** - the same recipients receive one notification when the first event in that incident has been marked as permanently failed after all attempts.

You do **not** get a notification per failed event. As soon as all failed deliveries for an endpoint have been resolved (successfully delivered), a following incident starts again with the same rules.

On **Profile menu → Developers**, the webhook table shows a compact delivery status per endpoint (numbers waiting for retry and permanently failed). Click the **ℹ** icon for details, including the full error message and the payload of the most recent attempt.

- **Retry failed deliveries** (↻): only permanently failed deliveries for that webhook.
- **Force retry** (⚡): all pending and permanently failed deliveries for that webhook, regardless of scheduled wait times. Tillor starts this in the background so that large queues (e.g. thousands of events) are processed safely.
- **Force retry all** at the top right next to **Add webhook**: the same for all enabled webhooks in the organisation.

---

## Event types [#event-types]

Event keys use the format `entity:action` or `entity:subresource:action`. The full list, with the permission per event and an example payload, is in the [Event index](/ontwikkelaars/events). That page is generated from the code and is therefore always complete. The same keys are in Tillor under [Profile menu → Developers](https://tillor.eu/orgs/org_abc123/developers) at **Add webhook** → **Subscribed events**.


---

## Webhooks vs SSE [#webhooks-vs-sse]

| Use case | Recommendation |
|----------|-------------|
| Server-side integration | **Webhooks** - Your server receives POSTs |
| Simple logging | **Webhooks** - Minimal setup |
| Realtime dashboard, live updates in an app | [SSE](/ontwikkelaars/sse) - One connection, low latency. |
| Many event types, client-side filtering | [SSE](/ontwikkelaars/sse) - Use the `events` query param to limit traffic. |

---

## Related [#gerelateerd]

- [OpenAPI](https://tillor.eu/api/openapi.json) - Full API specification
- [HTTP API](/ontwikkelaars/http) - REST API and API keys
- [SSE](/ontwikkelaars/sse) - Same events via Server-Sent Events
- [Automations](/ontwikkelaars/automatiseringen) - Send your own messages from an automation


# Website chat API (/en-GB/ontwikkelaars/website-chat)

You install the official widget in the app: see [Putting the chat on your website](/inbox/website-chat). Snippet options are on [Website chat settings](/inbox/website-chat-instellingen). This page is for developers: the widget SDK for your own form and the REST layer for a **custom chat UI**. See [OpenAPI](https://tillor.eu/api/openapi.json), tag `inbox`.

## Widget SDK [#widget-sdk]

After the widget script has loaded, `window.TillorInbox` is ready. With it you pass on contact details from your own form (contact page, sales detail page, quote request). All methods wait until the widget config has loaded.

| Method | Description |
|---------|--------------|
| `ready()` | Promise that resolves as soon as the widget has loaded |
| `getVisitor()` | Reads stored contact details from `localStorage` and filled-in widget fields; synchronous, no network |
| `setVisitor({ name?, firstName?, lastName?, email?, phone?, message?, customFields? }, options?)` | Fills in chat fields without sending |
| `open()` | Opens the chat window |
| `close()` | Closes the chat window |
| `toggle()` | Opens or closes the chat window |
| `send({ body, name?, firstName?, lastName?, email?, phone?, message?, customFields?, open?, silent?, markSubmitted?, metadata? })` | Sends a message with contact details |

`getVisitor()` returns this object:

| Field | Description |
|------|--------------|
| `visitorId` | ID of this visitor in this browser (`localStorage`) |
| `name` | Full name (a single field in the widget) |
| `firstName` / `lastName` | Derived from `name` (first word / rest) |
| `email`, `phone` | Contact details |
| `customFields` | Extra fields from the widget settings |
| `message` | Draft in the message field |
| `detailsSubmitted` | Whether the visitor form counts as filled in |

Use `getVisitor()` to prefill your own form from `localStorage` (same browser, also after a page refresh).

Options for `setVisitor` (second argument):

| Option | Default | Explanation |
|-------|-----------|--------|
| `open` | `false` | Open the chat window straight away |
| `markSubmitted` | `false` | Hide the visitor form if all required fields are filled in |
| `onlyEmpty` | `false` | Only overwrite empty fields |
| `persist` | `false` | Keep the details in `localStorage` (same browser, also after a new tab) |

Options for `send`:

| Option | Default | Explanation |
|-------|-----------|--------|
| `open` | `false` | Open the chat window before sending |
| `silent` | `true` if `open` is false | No sound, no error message in the widget; use the Promise for success or failure |
| `markSubmitted` | `true` | Contact details do not need to be entered again in the widget afterwards |
| `metadata` | - | Optional hints for Tillie (not visible in the chat window); see [metadata](#metadata-boekingsformulier) |

With `open: false` (default) the chat button stays closed. The message does go to Tillor; your own form can say thanks or show an error. With `open: true` the chat window opens and the visitor sees the normal sending behaviour (sound, ticks, any widget errors).

Want to use your own button instead of the floating chat button? Set `data-launcher="false"` on the snippet and call `TillorInbox.open()`.

### `metadata` (booking form) [#metadata-boekingsformulier]

Use `metadata` when you have your own form on the website and Tillie should send **only a confirmation**, without follow-up questions (for example because the tab closes afterwards).

| Key | Type | Explanation |
|---------|------|--------|
| `forceHandover` | `boolean` | Confirmation message and handover to a colleague, without intake questions. Also ignores the AI pause after a team message (see `ignoreAiPause`) |
| `ignoreAiPause` | `boolean` | Tillie also replies when she is paused in **Automatic** mode after a team message (30 minutes). Handy for silent form submission; combine with `forceHandover` or let Tillie do the intake as normal |
| `handoverIntent` | `"reservation"` \| `"caravan_rental"` \| `"sale"` \| `"other"` | Optional: flow for the handover (default: derived automatically from the message) |
| `source` | `string` | Optional integration label for your team (lowercase letters, digits, `-`, `_`; max. 64 characters) |

```javascript
await TillorInbox.send({
  name: "Jan Janssens",
  email: "jan@voorbeeld.be",
  phone: "+32 3 779 81 64",
  body: structuredBookingMessage,
  silent: true,
  metadata: {
    forceHandover: true,
    handoverIntent: "reservation",
    source: "website_booking_form",
  },
});
```

### Replacing the contact form (silent sending) [#contactformulier-vervangen-stille-verzending]

Use this when you want to keep the existing contact form, but have messages go through Tillor without opening the chat window.

```html
<form id="site-contact-form">
  <input name="name" type="text" required />
  <input name="email" type="email" required />
  <input name="phone" type="tel" />
  <textarea name="message" required></textarea>
  <button type="submit">Verstuur</button>
  <p id="contact-status" hidden></p>
</form>

<script>
  document.getElementById("site-contact-form").addEventListener("submit", async (event) => {
    event.preventDefault();
    const form = event.currentTarget;
    const status = document.getElementById("contact-status");
    const data = new FormData(form);

    try {
      await TillorInbox.send({
        name: String(data.get("name") ?? ""),
        email: String(data.get("email") ?? ""),
        phone: String(data.get("phone") ?? ""),
        body: String(data.get("message") ?? ""),
      });
      status.textContent = "Bedankt, we nemen snel contact op.";
      status.hidden = false;
      form.reset();
    } catch (error) {
      status.textContent = error instanceof Error ? error.message : "Versturen mislukt.";
      status.hidden = false;
    }
  });
</script>
```

You do not need to set `open` and `silent`: without `open: true` the window stays closed and Tillor treats the call as silent sending.

### Linking the contact form (opening the chat) [#contactformulier-koppelen-chat-openen]

Pass on fields and open the chat window, so that the visitor sees the conversation:

```html
<form id="site-contact-form">
  <input name="name" type="text" required />
  <input name="email" type="email" required />
  <input name="phone" type="tel" />
  <textarea name="message" required></textarea>
  <button type="submit">Verstuur</button>
</form>

<script>
  document.getElementById("site-contact-form").addEventListener("submit", (event) => {
    event.preventDefault();
    const form = event.currentTarget;
    const data = new FormData(form);
    void TillorInbox.send({
      name: String(data.get("name") ?? ""),
      email: String(data.get("email") ?? ""),
      phone: String(data.get("phone") ?? ""),
      body: String(data.get("message") ?? ""),
      open: true,
    });
  });
</script>
```

Or only fill in fields and open the window, without sending straight away:

```javascript
void TillorInbox.setVisitor(
  {
    name: "Jan Janssens",
    email: "jan@voorbeeld.be",
    phone: "+32 3 779 81 64",
    message: "Ik heb een vraag over de stacaravan te koop.",
  },
  { markSubmitted: true, open: true },
);
```

A sales page with immediate sending and opening the chat:

```javascript
void TillorInbox.send({
  name: "Jan Janssens",
  email: "jan@voorbeeld.be",
  phone: "+32 3 779 81 64",
  body: "Ik heb interesse in deze stacaravan.",
  open: true,
});
```

Syncing live while someone is typing:

```javascript
const form = document.getElementById("site-contact-form");
form.addEventListener("input", () => {
  void TillorInbox.setVisitor({
    name: form.name.value,
    email: form.email.value,
    phone: form.phone.value,
    message: form.message.value,
  });
});
```

### Calling early (before the widget script) [#vroeg-aanroepen-vóór-het-widget-script]

If you call a method before the script has loaded, put the call in the queue:

```html
<script>
  window.TillorInbox = window.TillorInbox || { q: [] };
  window.TillorInbox.q.push([
    "setVisitor",
    { name: "Jan", email: "jan@voorbeeld.be" },
    { open: true },
  ]);
</script>
<script src="https://tillor.eu/inbox-widget.js" data-org-id="org_abc123" data-widget-key="iwk_xxx" async defer></script>
```

## Custom chat UI [#eigen-chat-ui]

If you build your own chat UI instead of the widget, you use the REST layer below.

Authentication: header `X-Tillor-Inbox-Widget-Key` (value from *Settings > Integrations > Website chat*).

### Typing [#typen]

```http
POST /api/orgs/{orgId}/inbox/website/typing
X-Tillor-Inbox-Widget-Key: iwk_xxx
Content-Type: application/json

{
  "visitorId": "vis_…",
  "active": true,
  "visitorName": "Jan",
  "visitorEmail": "jan@voorbeeld.nl",
  "visitorPhone": "+32470123456"
}
```

- `active: true` when the visitor is typing; `false` when the field is empty or the visitor stops (the widget sends `false` after about 4 seconds without input)
- `visitorName` / `visitorEmail` / `visitorPhone` are optional
- Use the same `visitorId` as with `POST …/inbox/website/messages` and `GET …/inbox/website/messages`

### Realtime (SSE) [#realtime-sse]

```http
GET /api/orgs/{orgId}/inbox/website/subscribe?visitorId=vis_…
X-Tillor-Inbox-Widget-Key: iwk_xxx
Accept: text/event-stream
```

| Event | When |
|-------|-------|
| `inbox:website:message-created` | New team or AI message |
| `inbox:website:message-updated` | Team or AI message changed or deleted |
| `inbox:website:typing-changed` | `data.staffTyping` or `data.staffOutboundSenderType` changes |

The payload shape is the same as [org SSE](/ontwikkelaars/sse#event-formaat) (`event`, `data`, `timestamp`). Reconnect after a drop; there is no resumption.

The official widget uses SSE as its primary layer and fetches `GET …/messages` again every **5 seconds** as a fallback (every **1 second** with the panel open when SSE briefly drops). That way replies are marked as **delivered** as long as the visitor is on the page.

### Visitor activity [#bezoekersactiviteit]

```http
POST /api/orgs/{orgId}/inbox/website/events
X-Tillor-Inbox-Widget-Key: iwk_xxx
Content-Type: application/json
```

`event`: `chat_closed`, `tab_hidden` or `navigation` (with navigation also `url`). Your team sees these events as grey info text in the conversation, see [Conversations via Website chat](/inbox/website-chat-gesprekken).

### Limits [#limieten]

`POST …/inbox/website/messages` and `POST …/inbox/website/attachments/upload` answer `429` when a visitor or a network sends too much. The body carries `data.reason` = `INBOX_WIDGET_RATE_LIMITED` and `data.retryAfterSeconds`. Limits per organization:

| Route | Per visitor (`visitorId`) | Per network (IP address) |
|-------|---------------------------|--------------------------|
| `messages` | 10 per minute, 200 per day | 30 per minute, 600 per day |
| `attachments/upload` | 10 per hour | 50 per hour |

Wait `retryAfterSeconds` before you try again, and show the visitor a message instead of retrying on your own.

## See also [#zie-ook]

<Cards>
  <Card title="Website chat (app)" href="/inbox/website-chat" />
  <Card title="Website chat settings" href="/inbox/website-chat-instellingen" />
  <Card title="SSE" href="/ontwikkelaars/sse" />
  <Card title="OpenAPI" href="https://tillor.eu/api/openapi.json" />
</Cards>


# A guest at the barrier (/en-GB/praktijk/gast-aan-de-slagboom)

A guest arrives at the barrier of Recreatiepark Het Meer and needs to get through without help from reception. This example follows Jonas Maes from setting up his access method to what happens when it does not (or no longer) work. You will see how an access method, a controller and an access point work together.

```mermaid
flowchart LR
  A[Toegangsmethode bij de klant] --> B[Gast bij het toegangspunt]
  B --> C{Controller en Tillor controleren}
  C -->|geldig| D[Toegestaan, slagboom open]
  C -->|verlopen of geblokkeerd| E[Geweigerd, zichtbaar in het logboek]
```

Before you start:

- Your park has at least one access point that is linked to Tillor. It is under **Quick actions** on the **Access control** page with an **Open [access point name]** button.
- The controller at the barrier is linked to your organisation. A new controller appears under **Controllers** with **Pending approval** until you click **Approve**. See [Controllers](/controllers).
- For an NFC tag: the tag must already be in Tillor. That happens automatically as soon as it has been held up to a reader for the first time.

## The route step by step [#de-route-stap-voor-stap]

<Steps>
<Step>
### Add an access method [#voeg-een-toegangsmethode-toe]
Go to <UIPath>Customers > Jonas Maes > Access control</UIPath> and click **Add**. Choose the **Type** and optionally fill in a **From date** and **To date**. That period determines when the method works.

<DocScreenshot src="/screenshots/klanten/customer-access-control.png" alt="Access control tab with the Access methods table" />

<Tabs items={["Kenteken", "QR-code", "NFC-tag"]}>
<Tab value="Kenteken">
Choose **License Plate Recognition** and fill in the **License plate**. The camera at the access point reads the licence plate and Tillor finds the customer that goes with it.
</Tab>
<Tab value="QR-code">
Choose **QR Code**. Tillor creates the code itself. In the menu next to the method, copy the **Personal URL** and send it to Jonas. He opens the **Access pass** page and can add the pass to Apple Wallet or Google Wallet, if that is set up for your environment.
</Tab>
<Tab value="NFC-tag">
Choose **NFC** and select an available NFC card from the list. If the list is empty, first hold the tag up to a reader. See [Managing tags](/nfc/nfc-tags).
</Tab>
</Tabs>

See [Access control](/toegangscontrole).
</Step>
<Step>
### Check the controller and access point [#controleer-controller-en-toegangspunt]
The controller or the camera at the access point receives the list of valid methods from Tillor. Under **Controller Operations** on the **Access control** page you can see when a pass or QR code was forwarded to the access point. If the operation is not there yet, synchronisation is still in progress.

<DocScreenshot src="/screenshots/toegangscontrole/controller-operations.png" alt="Controller Operations with synchronisation and whitelist actions" />
</Step>
<Step>
### Follow what happens at the barrier [#volg-wat-er-aan-de-slagboom-gebeurt]
The **Access Log** block shows every attempt with date, method, customer, access point and status. A guest who drives in appears in the **Vehicles in park** table with the status **Inside**. When he drives out, that becomes **Left**.

<DocScreenshot src="/screenshots/toegangscontrole/access-log.png" alt="Access log with licence plates, customer and status" />
</Step>
<Step>
### Open the barrier yourself if needed [#open-de-slagboom-zelf-als-het-nodig-is]
Under **Quick actions**, click **Open [access point name]** and confirm with **Yes, open [access point name]**. Closing is only possible if the access point supports it.
</Step>
</Steps>

## What happens with an expired method? [#wat-gebeurt-er-bij-een-verlopen-methode]

Once the **To date** has passed, the method no longer gives access and the attempt appears in the log with the status **Expired**. Other statuses you will come across are **Blocked**, **Inactive** and **Denied**.

Licence plates have a grace period, so that guests do not end up in front of a closed exit at night. If **Allow expired license plates to exit** is on (default), the exit barrier still opens during the grace period. It lasts 2 days by default and 30 at most. It only works outside opening hours. If reception is open, staff handle the vehicle at the desk. A blocked or inactive licence plate never gets a grace period, and NFC tags and QR codes have no grace period. You set it under <UIPath>Support > Settings > Access control</UIPath>, see [Access control settings](/gebruikers/instellingen-toegangscontrole).

## What happens next? [#wat-gebeurt-er-daarna]

- Every attempt stays in the access log. You can filter by customer, status and access point and export to Excel.
- A vehicle that has not been seen at an access point for 7 days gets the status **Ghost**. If the licence plate is later seen at an entrance again, it goes back to **Inside**.
- If you extend the **To date** of the method, it works again after the next synchronisation with the access point.

## Problems? [#problemen]

<Accordions>
<Accordion title="The guest is standing at a closed barrier">
Find the attempt in the access log and read the status. **Expired** means the **To date** has passed, **Blocked** or **Inactive** means the method is switched off. If the method is fine, check **Controller Operations**. If you cannot fix it quickly, open the barrier via **Quick actions**.
</Accordion>
<Accordion title="There is no attempt in the log">
Then Tillor has not received anything. Check whether the controller is online and whether the screen shows a message. See [Screen messages](/controllers/troubleshooting/scherm) and [Connection problems](/controllers/troubleshooting/verbinding).
</Accordion>
<Accordion title="The licence plate is not recognised">
Check that the licence plate has been entered without spaces or typos. A misread licence plate can also leave a vehicle showing as **Ghost**.
</Accordion>
<Accordion title="I do not see an NFC card in the list">
The tag is not yet known in Tillor or is already attached to another customer. First hold it up to a reader, or detach it from the other customer.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Access control" href="/toegangscontrole" />
  <Card title="Controllers" href="/controllers" />
  <Card title="NFC" href="/nfc" />
  <Card title="Access control settings" href="/gebruikers/instellingen-toegangscontrole" />
</Cards>


# Overview (/en-GB/praktijk)

Most tasks touch more than one module: a new customer becomes an occupation, a contract, an invoice and a payment. These examples follow such a route from start to finish. They use the demo organisation Recreatiepark Het Meer, with customer Jonas Maes and pitch 12. Every step points to the page with the full explanation.

<Cards>
  <Card title="Winning a seasonal customer" href="/praktijk/seizoensklant-binnenhalen" description="Customer, occupation, rental contract, invoice, payment and payment report" />
  <Card title="Charging for usage" href="/praktijk/verbruik-aanrekenen" description="From meter on a pitch to automatic utility invoice" />
  <Card title="A static caravan becomes available" href="/praktijk/stacaravan-komt-vrij" description="Ending the occupation, follow-up task and deposit refund" />
  <Card title="A guest at the barrier" href="/praktijk/gast-aan-de-slagboom" description="Access method, controller, access point and what happens on expiry" />
</Cards>

## How does it fit together? [#hoe-hangt-dit-samen]

```mermaid
flowchart LR
  K[Klant] --> B[Bezetting]
  T[Terrein] --> B
  M[Meter] --> T
  B --> V[Verbruik]
  K --> O[Ondertekenverzoek]
  B --> F[Factuur]
  V --> F
  F --> P[Betaling]
  P --> R[Betalingsrapport]
  K --> TM[Toegangsmethode]
  TM --> TP[Toegangspunt]
  B -->|eindigt| A[Automatisering]
  A --> TK[Taak]
```

Read the examples as a route: you can join at any point. If you want to reread the terms, see [Terms](/begrippen).

## Terms [#begrippen]

- **Occupation**: a customer on a pitch for a longer period. See [Occupation](/begrippen#bezetting).
- **Pitch**: a spot in your park. See [Pitch](/begrippen#terrein).
- **Signing request**: a PDF that is signed online. See [Signing request](/begrippen#ondertekenverzoek).
- **Automation**: a rule that Tillor carries out itself. See [Automation](/begrippen#automatisering).


# Bringing in a seasonal customer (/en-GB/praktijk/seizoensklant-binnenhalen)

Bringing in a seasonal customer in Tillor means: create the customer, give them a terrain, have the rental contract signed, invoice the pitch fee and make sure the payment reaches your accounting. This example follows that route for Jonas Maes, who rents terrain 12 for the season at Recreatiepark Het Meer. Each step links to the page with the full explanation.

```mermaid
flowchart LR
  A[Create customer] --> B[Occupation on terrain 12]
  B --> C[Sign rental contract]
  C --> D[Invoice pitch fee]
  D --> E[Payment]
  E --> F[Payment report]
```

Before you start:

- Terrain 12 exists and has no active occupation. If it does have one, it does not appear in the list under **Create occupation**.
- There is a product with the action **Extend Occupation Period**, often Pitch fee. See [Linking actions to a product](/producten/acties-instellen).
- You have the rental contract ready as a PDF.
- You have the permission **Manage signature requests** to have the contract signed.
- For remote signing, the customer needs an email address or a phone number. A SEPA mandate needs an email address.

## The route step by step [#de-route-stap-voor-stap]

<Steps>
<Step>
### Create the customer [#maak-de-klant-aan]
Go to <UIPath>Customers > Overview</UIPath> and click **Create new customer**. If an identity scan is waiting in the queue, choose that scan in the dropdown: Tillor fills in the details from the document. Otherwise choose **Manual** and fill in **First Name**, **Last Name**, **Email address** and **Phone number**.

<DocScreenshot src="/screenshots/klanten/customer-create-dialog.png" alt="Create new customer dialog" />

After creating the customer you land on Jonas's profile. Complete the address there. You will find more under [Customer management](/klantenbeheer) and [Identity scans](/identiteitsscans).
</Step>
<Step>
### Give Jonas terrain 12 [#geef-jonas-terrein-12]
On his profile, open the **Overview** tab, go to the **Occupations** card and click **Create occupation**. Under **Terrain** choose terrain 12. If needed, fill in **Paid until**, the **Type** and the **Rent frequency**. The price comes from the terrain by default.

<DocScreenshot src="/screenshots/bezettingen/customer-occupations.png" alt="Occupations card on the customer profile" />

If terrain 12 has meters, you can also fill in the **Start meter readings** now. See [Occupations](/bezettingen#een-bezetting-aanmaken).
</Step>
<Step>
### Have the rental contract signed [#laat-het-huurcontract-tekenen]
Go to <UIPath>Administration > Signature requests</UIPath> and click **Request signatures**. Choose Jonas Maes as **Customer**, upload the contract, add Jonas as a signer with **Customer: Jonas Maes** and place a signature field. If you like, add a staff member as a second signer.

<Tabs items={["Remotely", "At reception"]}>
<Tab value="Remotely">
Click **Send**. Jonas receives an email with a personal link, or a text message if there is only a phone number. He signs on his own device and confirms with a 6-digit code.
</Tab>
<Tab value="At reception">
Click **Send**, open the request and click **Sign on tablet** next to Jonas. Choose **With a code**, or **Without a code** if you have checked his identity at the desk. The contract opens on the tablet, with his name in large letters.
</Tab>
</Tabs>

All the details are in [Requesting signatures](/handtekeningen/handtekening-vragen) and [How someone signs](/handtekeningen/ondertekenen).
</Step>
<Step>
### Book the pitch fee [#boek-het-staangeld]
Go back to the **Occupations** card on Jonas's profile, open the menu next to the occupation and choose **Extend occupation (invoice)**. Click **Create draft invoice**. Tillor creates a draft invoice with the product that has the action **Extend Occupation Period**. Check the period on the invoice and click **Book invoice**.

<DocScreenshot src="/screenshots/facturen/invoice-draft-detail.png" alt="Draft invoice with the Book invoice button" />

The invoice gets an invoice number and the status <Status tone="success">Booked</Status>. See [Booking an invoice](/facturen/boeken) and [Extending an occupation](/bezettingen#facturatie-bezetting-verlengen).
</Step>
<Step>
### Choose how Jonas pays [#kies-hoe-jonas-betaalt]
Booking sends nothing to the customer. Now you choose how the money comes in.

<Tabs items={["Payment link", "Direct debit with mandate", "At reception"]}>
<Tab value="Payment link">
Click **Send notification** and choose a channel such as **Email**. Jonas receives the **View and pay online** button and completes the payment with, for example, iDEAL or Bancontact. If he wants to pay only part of it first, create a [link for a partial payment](/facturen/betalingen-registreren#een-link-voor-een-deelbetaling-maken). See [Paying online](/betalingsverwerking/online).
</Tab>
<Tab value="Direct debit with mandate">
First request a mandate via <UIPath>Customers > Jonas Maes > Invoicing</UIPath> and **Create Mandate**. As soon as the status is <Status tone="success">Active</Status>, choose that mandate on the invoice under **Direct-debit mandate**. Tillor then collects the amount two days after booking, or two days after linking if the invoice was already booked. See [Having a SEPA mandate signed](/betalingsverwerking/mandaat) and [Collecting an invoice by direct debit](/betalingsverwerking/incasso).
</Tab>
<Tab value="At reception">
Click **Make payment** and choose **Terminal**, **Cash** or **Bank Transfer**. See [Registering a payment](/betalingsverwerking/betaling-registreren).
</Tab>
</Tabs>
</Step>
<Step>
### See the payment come in [#zie-de-betaling-binnenkomen]
The payment appears under <UIPath>Administration > Payments</UIPath>. An online payment shows up as soon as Mollie confirms it. A direct debit first has the status <Status tone="warning">Pending</Status> and becomes <Status tone="success">Paid</Status> after a few days. Once everything is in, the invoice is <Status tone="success">Paid</Status>.

<DocScreenshot src="/screenshots/betalingen/payments-list.png" alt="Overview of all payments" />

You will find more under [Finding payments](/betalingsverwerking/betalingen-bekijken).
</Step>
<Step>
### See the payment in the payment report [#zie-de-betaling-in-het-betalingsrapport]
Go to <UIPath>Administration > Payment Reports</UIPath>. Today's payments are on the report with the status **Draft**. Tillor finalises the report at the next daily check, on working days at 09:00. If your accounting integration is active, Tillor sends the report on by itself.

<DocScreenshot src="/screenshots/boekhouden/betalingsrapporten/payment-reports-list.png" alt="List of payment reports" />

See [Payment reports](/boekhouden/betalingsrapporten).
</Step>
</Steps>

## What happens next [#wat-gebeurt-er-daarna]

- Jonas's occupation is running. Terrain 12 is no longer available to other customers and the consumption of the meters on the terrain goes to Jonas.
- Once everyone has signed, the request has the status <Status tone="success">Completed</Status>. The signed PDF with proof pages is in his **Documents**. If you want an automation to do something then, for example create a task, use the trigger **Signature request completed**.
- When the invoice is booked, Tillor sets **Invoiced until** to the end of the invoice line. After payment, **Paid until** moves forward. See [Paid until, type, rent frequency and price](/bezettingen#betaald-tot-type-huurfrequentie-en-prijs).
- Next season you extend the same occupation again with **Extend occupation (invoice)**, or for all of a customer's occupations at once with **Extend all**.
- Mollie payments appear on the draft report as an advance on Mollie, until the payout is known.

## Problems? [#problemen]

<Accordions>
<Accordion title="Terrain 12 is not in the list under Create occupation">
A terrain can only be linked to one customer at a time. If there is already an active occupation, it does not appear in the list. End that occupation first, see [Ending an occupation](/bezettingen#een-bezetting-beëindigen).
</Accordion>
<Accordion title="I cannot send the signature request">
Tillor checks the request and tells you what is missing: a signer without a signature field, a signer without an email address or phone number, or an empty title. Fix it and try again. See [Requesting signatures](/handtekeningen/handtekening-vragen#problemen).
</Accordion>
<Accordion title="The Book invoice button is grey">
Hover over the button with your mouse, Tillor shows the reason. Often a start or end date is missing on a line with an occupation, or the amount is higher than the maximum of the linked mandate. See [When booking fails](/facturen/boeken#problemen).
</Accordion>
<Accordion title="Extend occupation (invoice) gives no usable invoice">
At least one product with the action **Extend Occupation Period** must exist. Without such a product Tillor cannot build the line. Create the product or add the action, see [Linking actions to a product](/producten/acties-instellen).
</Accordion>
<Accordion title="SEPA Mandate is grey under Make payment">
Jonas has no mandate with the status <Status tone="success">Active</Status> whose maximum amount is high enough. Check the **Mandates** card on his **Invoicing** tab.
</Accordion>
<Accordion title="The invoice is In Progress">
The payment has started, but the money is not definitively in yet. That is normal with a direct debit. Once the payment is processed, the status changes to **Paid**. See [Statuses](/facturen/statussen).
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Charging consumption" href="/praktijk/verbruik-aanrekenen" description="The follow-up: the water and electricity Jonas uses" />
  <Card title="Occupations" href="/bezettingen" />
  <Card title="Signatures" href="/handtekeningen" />
  <Card title="Invoices" href="/facturen" />
  <Card title="Payment processing" href="/betalingsverwerking" />
</Cards>


# A static caravan becomes vacant (/en-GB/praktijk/stacaravan-komt-vrij)

When a customer leaves a static caravan, there is work to do: the caravan has to be checked and the deposit has to go back to the customer. This example shows how Tillor brings that together. You end the occupation, an automation creates a follow-up task, a colleague completes the task and then you settle the deposit. We use Jonas Maes and terrain 12 of Recreatiepark Het Meer as the example, now as a tenant of a static caravan.

```mermaid
flowchart LR
  A[End occupation] --> B[Automation]
  B --> C[Follow-up task with subtasks]
  C --> D[Colleague completes it]
  D --> E[Deposit back via credit note]
```

Before you start:

- Terrain 12 has the terrain type **Stacaravan** and Jonas has an active occupation on it. See [Terrain types](/terreinen#terreintypes).
- An automation is ready that creates a task when an occupation ends. How to build it is described in [Example: checking a rental caravan](/automatiseringen/voorbeeld-nalopen). In demo environments it is already set up under the name **Nalopen huurcaravan**, paused, until you turn on the **Active** switch.
- For the deposit: the deposit product has the option **Guard the customer's balance on this ledger** turned on. See [Guarding the customer's balance](/producten/product-aanmaken#het-saldo-van-de-klant-bewaken).

## The route step by step [#de-route-stap-voor-stap]

<Steps>
<Step>
### End the occupation [#stop-de-bezetting]
Open Jonas's profile, go to the **Occupations** card on the **Overview** tab, open the menu next to the occupation and choose **Delete**. Under **Date** choose the day he leaves. If the terrain has meters, fill in the **End meter readings**. Click **Delete**.

<DocScreenshot src="/screenshots/bezettingen/customer-occupations-actions-menu.png" alt="Actions menu for an occupation" />

Terrain 12 is then free again for a new occupation. See [Ending an occupation](/bezettingen#een-bezetting-beëindigen).
</Step>
<Step>
### Let the automation create the follow-up task [#laat-de-automatisering-de-nalooptaak-maken]
You do not have to do anything. The automation starts as soon as the occupation ends and first checks whether the terrain has the terrain type **Stacaravan**. Then it looks for an open task **Nalopen** for this terrain.

- If there is no open task yet, it creates a task **Nalopen terrein 12** with five subtasks (**Kuisen**, **Inboedel**, **Internet + TV**, **Kader QR code** and **Controleren op werkjes**) and a deadline after 7 days. The task also goes to the colleague who ended the occupation.
- If there is already an open task, for example because the caravan became vacant twice in quick succession, it does not create a second one. The priority of the existing task goes up one step, to **High**.

<DocScreenshot src="/screenshots/automatiseringen/task-step.png" alt="Create follow-up task step in the automation" />

You can follow what the automation did under [Tests and runs](/automatiseringen/testen-en-uitvoeringen).
</Step>
<Step>
### Complete the task [#werk-de-taak-af]
The colleague finds the task in the **Tasks for you** card on the dashboard, on Jonas's **Tasks** tab, or in a view under **Tasks**. The task is linked to terrain 12 and to Jonas.

<DocScreenshot src="/screenshots/taken/task-detail-dialog.png" alt="Task window with description, subtasks and properties" />

<Tabs items={["With subtasks", "With choice buttons"]}>
<Tab value="With subtasks">
Open the task and tick off each subtask as soon as it is done. Next to the task there is a counter such as **2/5**. When all subtasks are done, set the status to **Completed**. If you set the main task to **Completed**, the open subtasks are completed with it.
</Tab>
<Tab value="With choice buttons">
If you have extended the automation with the step **Ask for a decision**, for example to decide whether the deposit is refunded in full, there are buttons on the task under **Choose an action to finish this task**. One click completes the task. If the choice asks for a reason, **Why this choice?** opens. A choice that has been made can no longer be undone. See [Tasks with choice buttons](/taken/taakdetails#taken-met-keuzeknoppen) and [Ask for a decision](/automatiseringen/logica#vraag-om-een-beslissing).
</Tab>
</Tabs>
</Step>
<Step>
### Check the deposit balance [#controleer-het-saldo-van-de-waarborg]
Open Jonas's profile and go to the **Invoicing** tab. In the **Accounts** table you see the balance per ledger. The deposit ledger shows what Jonas is still owed.
</Step>
<Step>
### Create the credit note for the deposit [#maak-de-creditnota-voor-de-waarborg]
Open Jonas's deposit invoice, click the three dots at the top right and choose **Reverse invoice**. Tillor creates a draft invoice with the same lines in negative amounts. If you keep part of it, for example for damage, adjust the amount. Click **Book invoice**. The invoice becomes a **Credit Invoice**.

Tillor refuses an invoice that would bring the balance of the deposit ledger below zero. This way you cannot refund a deposit twice. See [Reversing an invoice](/facturen/corrigeren#een-factuur-omkeren).
</Step>
<Step>
### Offset the amount [#verreken-het-bedrag]
If Jonas still has an open invoice, for example for the last consumption, you can offset the amount with the payment method **Internal Transfer**. See [Making an internal transfer](/betalingsverwerking/interne-overboeking).
</Step>
</Steps>

<Callout type="info" title="Paying money back">
Tillor records the credit note and the offsetting. Transferring the money itself back to the customer's bank account is something you do through your bank.
</Callout>

## What happens next [#wat-gebeurt-er-daarna]

- The terrain is free again. A new customer can take an occupation on it or get a reservation on it.
- Jonas's open consumption periods are closed, with the end readings you filled in. The consumption up to the end date is kept and you can still invoice it. See [Charging consumption](/praktijk/verbruik-aanrekenen).
- The task and the actions on it are in the task's timeline and on Jonas's profile. Changes to the occupation are on his **Events** tab.
- The credit note goes into the accounting like any other invoice.

## Problems? [#problemen]

<Accordions>
<Accordion title="No follow-up task was created">
Check three things. Is the **Active** switch of the automation on? Is the terrain type of terrain 12 **Stacaravan**? Look under [Tests and runs](/automatiseringen/testen-en-uitvoeringen) to see whether the automation started and where it stopped.
</Accordion>
<Accordion title="There are two follow-up tasks, or only one">
The automation looks for an open task with exactly the same title, **Nalopen** followed by the terrain name, for the same terrain, the same customer or the same reservation. If the title does not match, it does not find the existing task and creates a new one. An open task only gets a higher priority, not a second task.
</Accordion>
<Accordion title="I cannot complete the task">
If it says **Finished by its automation**, only the automation can complete the task and the task has no **Delete**. See [Task details](/taken/taakdetails#taken-met-keuzeknoppen).
</Accordion>
<Accordion title="I do not see the choice buttons">
Anyone assigned to the task and an administrator can choose. If nobody is assigned, anyone who sees the task can choose. If there is a tick instead of buttons, the task does not come from an **Ask for a decision** step.
</Accordion>
<Accordion title="Book invoice is grey on the deposit credit note">
The balance of the deposit ledger would drop below zero. Check the **Accounts** table and the amount on the invoice. With the permission **Override ledger balance** you can book anyway, with a justification that goes into the invoice's timeline.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Example: checking a rental caravan" href="/automatiseringen/voorbeeld-nalopen" description="This is how you build the automation yourself" />
  <Card title="Tasks" href="/taken" />
  <Card title="Correcting an invoice" href="/facturen/corrigeren" />
  <Card title="Occupations" href="/bezettingen" />
</Cards>


# Charging consumption (/en-GB/praktijk/verbruik-aanrekenen)

Charging consumption in Tillor works through the terrain: a meter belongs to a terrain, a customer gets onto the terrain through an occupation, and the meter's consumption goes to that customer. This example follows the electricity meter on terrain 12 of Recreatiepark Het Meer, from the link to the invoice for Jonas Maes. At the end it explains how Tillor can also create and send that invoice by itself.

```mermaid
flowchart LR
  A[Meter] -->|link| B[Terrain 12]
  B --- C[Jonas's occupation]
  A -->|meter readings| D[Jonas's consumption]
  D --> E[Outstanding consumption]
  E --> F[Invoice]
  F -.->|automatic| G[Utility invoice on a fixed day]
```

Before you start:

- The meter already exists under <UIPath>Park > Meters</UIPath> and is not yet linked to a terrain. A meter that is already on a terrain does not appear in the list.
- Jonas has an active occupation on terrain 12. See [Bringing in a seasonal customer](/praktijk/seizoensklant-binnenhalen). Without an occupation Tillor does not know who the consumption belongs to.
- For the automatic invoice Jonas needs an email address or phone number, and for automatic collection an active mandate.

## The route step by step [#de-route-stap-voor-stap]

<Steps>
<Step>
### Link the meter to terrain 12 [#koppel-de-meter-aan-terrein-12]
Go to <UIPath>Park > Terrains</UIPath>, open terrain 12 and scroll to the **Meters** card. Click **Add meter**, choose the meter and click **Assign meter**.

<DocScreenshot src="/screenshots/park/terrain-detail.png" alt="Detail page of terrain 12 with the Meters card" />

See [Meter management](/meterbeheer/meter-koppelen) and [Terrains](/terreinen).
</Step>
<Step>
### Record the starting reading [#leg-de-beginstand-vast]
If Jonas is already registered on terrain 12, enter the starting reading on the occupation. If you are only creating the occupation now, fill in **Start meter readings**. If you leave it empty, Tillor takes the last known reading. This way the first consumption batch starts at the right reading straight away. See [Occupations](/bezettingen#een-bezetting-aanmaken).
</Step>
<Step>
### Follow the meter readings [#volg-de-meterstanden]
Smart meters send their reading by themselves, usually daily or weekly. A manual meter you read and enter yourself. See [Meter management](/meterbeheer).

You can see the consumption in two places. On the meter page under <UIPath>Park > Meters</UIPath> there is the **Consumption** card with, per customer, the outstanding and settled consumption. On Jonas's profile there is the **Readings** card, with all the meters on his terrains.

<DocScreenshot src="/screenshots/park/meter-detail.png" alt="Meter page with the Consumption card" />

If someone enters a reading that is lower than the previous one, Tillor warns you. If the reading is correct after all (the meter has been replaced), Tillor closes the current period and starts a new one. See [Consumption batches](/meterbeheer/consumptie-batches).
</Step>
<Step>
### See what is outstanding [#bekijk-wat-openstaat]
Go to <UIPath>Customers > Outstanding Consumption</UIPath>. You see per customer the total amount, the **Last utility invoice** and the number of meters. Jonas appears as soon as there is consumption that is not yet on an invoice.

<DocScreenshot src="/screenshots/meterbeheer/outstanding-consumption.png" alt="Customers overview with outstanding consumption" />
</Step>
<Step>
### Create the invoice [#maak-de-factuur]
You have two ways.

<Tabs items={["From the list", "From the customer profile"]}>
<Tab value="From the list">
At the end of Jonas's row, click the send icon. The **Create invoice** window shows the total amount, the breakdown per type and the number of meters. Tick the channels Tillor should use to send the invoice straight away and click **Create invoice**. Tillor creates the invoice, books it and sends it. If Jonas has a mandate for utility invoices, it is preselected under **Collect with mandate**.
</Tab>
<Tab value="From the customer profile">
Open Jonas's profile and click **Invoice consumption** in the **Readings** card. For each consumption period Tillor adds a main line with an info line below it showing the date and the meter readings. If a suitable draft invoice already exists, the lines go on that. Check the invoice, then book and send it yourself. See [Booking an invoice](/facturen/boeken) and [Sending an invoice](/facturen/versturen).
</Tab>
</Tabs>
</Step>
<Step>
### Let Tillor do it by itself [#laat-tillor-het-zelf-doen]
Open Jonas's profile, go to <UIPath>Customers > Jonas Maes > Invoicing</UIPath> and open the **Invoice Settings** card. There you set:

- **Automatic utility billing**: a day of the month. If you choose 31 and the month does not have 31 days, the invoice goes out on the last day of the month.
- **Mandate**: the mandate Tillor uses to collect the utility invoice. See [Collecting an invoice by direct debit](/betalingsverwerking/incasso#nutsfacturen-automatisch-innen).
- **Minimum amount**: a lower limit of its own for Jonas. If you leave it empty, the organisation's minimum under <UIPath>Support > Settings > Invoicing</UIPath> applies.

On the chosen day Tillor creates the invoice by itself and sends it. If the outstanding amount is below the minimum, Tillor waits until a later invoice day.
</Step>
</Steps>

## What happens next [#wat-gebeurt-er-daarna]

- The invoiced consumption periods are completed. If the occupation continues, Tillor starts a new period at the end reading of the previous one, so there is no gap.
- Once the invoice is booked, it carries on like any other invoice: payment, reminder and payment report. See [Bringing in a seasonal customer](/praktijk/seizoensklant-binnenhalen).
- When the occupation ends, Tillor closes the open periods. The consumption up to the end date is kept and you can still invoice it.
- If you delete a draft invoice with consumption, the consumption returns to **Outstanding Consumption**.

<Callout type="info" title="Consumption well above the usual">
If the outstanding electricity or water consumption is at least double what Jonas normally uses, Tillor does not create the automatic invoice. You receive an email at the organisation's support address. Check the meter reading and invoice the consumption yourself if everything is correct.
</Callout>

## Problems? [#problemen]

<Accordions>
<Accordion title="The meter is not in the list under Add meter">
The list only shows meters without a terrain. If the meter is already on another terrain, first unlink it via the menu next to the meter on that terrain, with **Unlink from terrain**.
</Accordion>
<Accordion title="Jonas has no consumption on the meter of terrain 12">
The consumption goes to the customer with an active occupation on the terrain. Check whether Jonas has an occupation on terrain 12 and whether the meter is on the terrain.
</Accordion>
<Accordion title="Jonas is not in Outstanding Consumption">
By default the list only shows customers without automatic billing. Set the filter **Automatic billing** to **Has date** to see customers with an automatic invoice day.
</Accordion>
<Accordion title="The automatic invoice was not created">
There are two common reasons. The outstanding amount is below the minimum, in which case Tillor waits for a later invoice day. Or the consumption is well above the usual, in which case you receive an email at the support address and the invoice is held back until someone has checked it. See [Meter management](/meterbeheer/verbruik-factureren#automatisch-factureren).
</Accordion>
<Accordion title="I have already invoiced the consumption outside Tillor">
Open the period in the **Readings** or **Consumption** card, click the warning icon next to the period and confirm with **Yes, mark as invoiced**. The period then closes without an invoice. You can only undo this for periods without an invoice link.
</Accordion>
</Accordions>

## See also [#zie-ook]

<Cards>
  <Card title="Meter management" href="/meterbeheer" />
  <Card title="Consumption batches" href="/meterbeheer/consumptie-batches" description="How consumption periods are tracked and invoiced" />
  <Card title="Collecting an invoice by direct debit" href="/betalingsverwerking/incasso" />
  <Card title="Invoicing settings" href="/gebruikers/instellingen-facturatie" />
</Cards>