Jobs run fully hands-off: the server checks which jobs are due and executes them in order. You simply create a job, set its schedule, and the server does the rest.
The Scheduler lets you run EBICS operations automatically, driven by standard cron expressions and a single system crontab entry. Instead of triggering each download or upload by hand, you define a job once and the server executes it on time — fetching files from the bank or sending prepared files to it.
Every job is bound to one bank connection and one order type, and can optionally call a webhook when it finishes. Files produced by jobs are stored encrypted and become searchable.
For step-by-step visual instructions check out the presentation slides — they walk you through completing the setup.
A download job periodically retrieves data of a given order type from the connected bank. On every run, the server connects to the bank, fetches the requested order type — bank statements, reports, documents — and stores the result as an encrypted, searchable file.
You choose the order type to retrieve, set the schedule, and the job takes care of the rest. Each run produces a file that can be browsed, searched and downloaded later.
Set a cron schedule and the server runs the job automatically when it is due.
Fetched files are stored encrypted and become searchable by content.
On completion, an optional webhook can be called with the result.
Scheduler Job Files is your archive of job results.
Every scheduler job run produces files that the server stores as encrypted, searchable archives. The Files view of a job lists each file with its creation date, connection, order type, and size, so you always know what a job fetched from or sent to the bank.
The list is searchable by file content and filterable by date, and it stays fast even for jobs that run thousands of times. Downloading any file takes one click, and the same capability is available through the API for pulling documents into your own systems.
Deleting a job removes its files automatically, leaving no orphaned data behind.
For upload jobs, the scheduler relies on a per-job upload queue — a private directory where you prepare the files the bank should receive. You create an upload job by selecting the connection and order type (CCT, CDD, CIP, FUL, BTU, and similar), defining a cron schedule, and setting a path expression that tells the job which filenames to look for. From then on, the queue is your staging area: you upload payment or document files into it, and on every scheduled run the job picks up each file that matches the path expression and sends it to the bank. You stay in full control between runs — files can be renamed, replaced, previewed, or removed at any time. The queue even detects the planned upload time from each filename, so you can stage a payment now and let the job deliver it on its scheduled date. Everything happens automatically from that point on.
The queue is fully manageable — upload new files, rename them, replace their content, or delete them at any time, even after they have been queued. A path expression decides which queued files are sent; it supports date placeholders such as year, month, day, and hour, plus wildcards, so a filename like payment-2026-08-04.xml tells the job when the file is due. Every queued file is marked with a status — scheduled for upload, pending, not matching the expression, or outdated — so you always know what the next run will send.
Files whose date has passed are left untouched, and an optional webhook notifies you when the upload completes.
Both job types can call a webhook URL when they finish. A successful run reports the result and where to find the produced file; a failed run reports the error. This makes it easy to integrate the scheduler with your own systems — receive a notification, react to a failure, or fetch the file as soon as it is ready.