Recurring Payments

Some payments never change: the office rent on the 1st, a leasing rate on the 15th, an insurance premium each quarter. Recurring Payments lets you set such a payment up once with its payee, amount and dates. neoo then creates it on schedule, and you can see at any time what was created, when, and what became of it.

Navigate to Cockpit → Recurring Payments (requires the recurring-payments permission). The page has two views: Schedules, the list of everything you have set up, and Run history, one line per payment a schedule has created.

Two kinds of schedule#

Pick the kind when you create a schedule; it cannot be changed afterwards.

Direct payment — a standing order. On each date neoo creates a payment line for the payee and queues it in Bank Payments, where it is selected, exported or uploaded together with your bills — one pain.001 file for everything that goes out that day. No vendor transaction is involved, so nothing is booked until the bank debit arrives; what happens then is decided by the settlement account (see below). Use this for payments that are not bills in your books — a rent paid to a private landlord, a loan instalment, a fixed transfer to another company account.

Vendor transaction — a recurring bill. On each date neoo posts an approved vendor transaction for the chosen vendor with the expense lines and tax you defined, dated the day it is created and due on the payment date. Tick Queue the payment in Bank Payments and the transaction is also flagged for payment, so it appears in Bank Payments with the vendor’s bank account, ready to be sent; the bank debit is then matched to it exactly as for any other bill. Use this for everything that belongs in your books as an expense — rent, leasing, subscriptions, retainers. This kind requires the vendor-transaction permission as well.

Amounts are fixed per schedule. Bills whose amount changes each period — electricity, telephone — are better handled through the Inbox, where the document sets the amount.

Setting up a schedule#

Click New schedule. The form is on the left; the panel on the right reads your schedule back as you fill it in: the amount and payee, the schedule as a sentence, the next four payment dates with the day each will be created, and the booking that will result. Issues are listed there when you try to save.

Payee#

For a direct payment enter the payee’s name, IBAN and structured address (street, number, postal code, city, country) — the same details a vendor needs before a bill can be paid. neoo checks the IBAN, refuses your own bank accounts, and tells you what a particular payment needs: a BIC for a transfer outside Switzerland and the SEPA area, a QR reference if the IBAN is a QR-IBAN. Fill in from a vendor copies name, address and bank details from a vendor record if the payee is one.

Payment reference is optional and recognised from what you type: a 27-digit QR reference (only with a QR-IBAN) or an ISO creditor reference starting with RF, both checked for valid check digits. Because the reference repeats on every payment, only use one the payee issued for recurring payments, such as a standing-order QR bill; a reference from a single invoice must not be reused. A payee whose account is a QR-IBAN cannot be paid without a QR reference, so without a standing reference ask them for a normal IBAN. The Message to payee is the free text on their statement and the right place for anything that changes per payment.

For a vendor transaction choose the Vendor; the creditor account, payment terms and currency are taken from the vendor record. If the payment is queued, pick the Vendor bank account the money goes to and, where the vendor issued one for recurring payments, the QR or creditor reference — the same rules as above apply.

Amount and booking#

A direct payment has one Amount and Currency, and the bank account it is drawn on. A vendor transaction has expense lines — account, description, tax and amount — whose total is the payment; tick Amounts include tax when the amounts are gross. The tax on a line is always one of the vendor’s own tax accounts (set on the vendor), and each line keeps its own tax, so a tax-free line in a mixed bill is booked at its full amount. An optional vendor invoice number completes the transaction; it is due on the payment date.

Descriptions, the message to the payee and the invoice number accept date variables that are filled in at each run: {month}, {month-1}, {month+1}, {year} and {date}. Rent {month} {year} becomes “Rent October 2026” on the October run.

Payment dates#

The schedule defines the payment date: the execution date of the direct payment, or the due date of the vendor transaction. If a payment date falls on a weekend, a direct payment asks for the next bank working day. The date can still be changed on the row in Bank Payments, or overridden by a batch value date.

Document#

Attach the contract, standing order or QR bill the payments are based on — one PDF per schedule. It is kept on the schedule rather than on every generated payment or transaction, so an auditor can see where a payment comes from in one place. Schedules with a document show a PDF icon in the list; hover it for a preview, click it to open the file. Replacing or removing the document only affects the schedule, never the payments already created.

When the bank debit arrives (direct payments)#

A direct payment has no vendor transaction, so decide here how the bank debit is booked when the statement comes in:

• With a Settlement account, the debit is booked automatically on bank import: the bank recognises the payment by the reference neoo wrote into the file, the settlement account is debited and the bank credited, in one entry, and the payment is marked completed. Add a Tax account and the amount is split into net and VAT at that account’s rate, so a rent paid with 8.1% VAT lands as net rent plus input tax.
• Without a settlement account the debit is an ordinary unmatched bank transaction on your transition account, to be matched by hand in Bank Matching — for example against the payment with Settle payment file.

The list#

Each row shows the schedule’s name and kind, the payee, the amount, the schedule, the next payment date with the day it will be created, the last run with its result, and the status: Active, Paused, or Needs attention.

From the row you can:

• Run history — the runs of this schedule.
• Edit — change anything except the kind. Changes only affect future payments.
• Run now — create the next payment immediately, ignoring the lead time and run time. The dialog shows the payment date it will use. A date that already has a payment is never created twice.
• Pause / Resume — a paused schedule creates nothing. Resuming never back-fills the dates that passed while it was paused; it continues with the next one.
• Delete — removes the schedule and its run history. Payments and transactions already created are not affected.

Needs attention#

If a run fails — a vendor was deleted, a bank account lost its IBAN, no exchange rate was available — the schedule pauses itself instead of failing again every day, and the list marks it Needs attention with the reason. Fix the cause, Resume the schedule and use Run now to create the payment that was missed.

Run history#

The Run history view lists every payment any schedule has created, newest first, and can be narrowed to one schedule or searched. Each line shows when it ran and whether it was scheduled or started with Run now, the payment date, the amount, the result, and what was created: the vendor transaction (click to open it) and the payment file with its current state in Bank Payments — created, exported, uploaded or completed — so “was it actually sent?” is answered here. Failed runs show the error.

Direct payments created by a schedule carry a Direct payment · Recurring chip in Bank Payments. They behave like any other row there — select them with your bills, change the execution date or amount while they are still in Created, export or upload them — except that the API rails (Amnis, Revolut, Wise) do not take them, as those rebuild each transfer from a vendor invoice.