When switching to Iteras and you have existing Betalingsservice payment agreements (hereafter simply referred to as BS agreements), the Betalingsservice setup must be migrated to Iteras.
Timing and Planning
Well before going live with Iteras, the BS migration should be timed and planned — as Egon Olsen would have said — and with the same precision he would have applied.
If no existing BS agreements are in place, timing is not as critical. In that case, the Betalingsservice agreement only needs to be updated so that Iteras becomes the data provider and the settings on the agreement match Iteras.
Read more about how to update your Betalingsservice agreement with Iteras as the data provider. We strongly recommend keeping the existing FIK number for payment slips, as it otherwise takes time for subscribers to adapt to the new FIK number.
If there are existing BS agreements, you will generally want to continue billing on these agreements after the switch to Iteras. This causes the least inconvenience for subscribers, who will not need to re-register for BS.
The BS Agreement Conversion Can Include:
Moving the agreements to a new PBS number, if a new PBS number has been created in connection with the transition to Iteras.
This may be relevant if the existing PBS number has also been used for purposes other than subscriptions (e.g., advertisements) and you want to continue that use. Iteras cannot share a PBS number with other functions, so in that case a completely new PBS number must be created. However, it should be carefully considered whether subscriptions should keep the existing PBS number, as there are usually more transactions on subscriptions than, for example, advertisements.
Replacing the subscriber number, if the old subscriber numbers are not carried over into Iteras. We often see that BS agreements in previous systems have been tied to subscription numbers rather than subscriber numbers. In Iteras, they are linked to subscriber numbers, which may require converting the BS agreements to the new Iteras subscriber numbers (whether these are genuinely new, or it’s simply a change from subscription-level to subscriber-level in the agreements).
From a timing perspective, the latter means that the new subscriber numbers must be known before the BS agreements can be converted. This means the conversion cannot begin until after the data migration to Iteras.
BS agreements cannot be migrated if there are “pending” payments.
This will typically be the case from around the 20th of the month (when BS’s submission deadline for the following month’s payment requests occurs) until the third banking day after the 7th (when the rejection deadline expires, assuming the payment date is the 1st — otherwise it’s two business days plus one day).
The conversion window therefore opens around the 10th (but can also be the 12th if the 7th is a Friday) and closes around the 22nd–24th, depending on the month.
The exceptions are if no BS payments have been submitted — for example, because no one needed to be billed that month (often unlikely) — or because you decide to delay billing until the next month for migration reasons.
However, delaying a month’s BS billing by a month can put pressure on liquidity, so we generally try to avoid this in planning.
If you are also changing CVR number, it may be possible to perform the migration via Excel files sent to BS, as BS has special procedures when a CVR change is involved (this is not simply allowed — their legal team must ensure no irregularities are taking place). In that case, you must book time with BS well in advance, as they may otherwise be too busy to assist.
You should begin as soon as the window opens, and not leave it until the last minute, to allow time to correct any errors. BS will only verify once per day that the conversion was successful — in other words, you get one shot per day.
Note: The PBS number must be converted before the BS agreements can be converted.
This can advantageously be done before the conversion window opens so you don’t waste valuable time on this step, which will also take a day at BS.
This step can be done even if there are pending payments.
After the migration, payments will be processed through Iteras. Payments may still arrive on the PBS number for invoices issued in the old system. These will not match invoices in Iteras and will therefore appear on the error list in Iteras.
From there, they can either be exported for registration in the old system, or matched to invoices in Iteras that correspond to the outstanding amount in the old system (if created in Iteras).
This means you can, in principle, convert the PBS number as soon as you are ready to accept payments through Iteras — which will typically “break” the automation in the old system’s payment processing (if it was automated). For this reason, you might do it a few days earlier, e.g., on the 1st of the month.
A particular consideration here is outstanding BS payments, which can be numerous.
This may argue for retrieving the BS payment file before converting the Nets creditor number.
In Conclusion: The Nets Conversion Plan Will Look Like This:
PBS number: Preferably start before the 10th of the month so you are ready — but note that payments will then be processed via Iteras, including BS payment requests!
BS agreements: Start as soon as the conversion window opens, around the 10th of the month
Migration Roadmap
1. Well in advance of the migration, and provided that the existing PBS number will be continued (otherwise not)
Iteras contacts Betalingsservice to review the PBS number setup and ensure it is adjusted to Iteras’ requirements. In practice, this means:
Check that it is a Total Agreement, which can also send payment slips.
Check that the correct FI numbers are linked.
Check that the agreement is active and usable.
Check that automatic notifications are sent on the payment date.
Check whether 603 deliveries are enabled: daily sign-ups and cancellations, as well as monthly delivery.
Check whether 605 deliveries are enabled.
2. Around the 1st of the month OR as soon as the last file with BS payments issued by the old system has been received
The customer submits a request for Iteras to become the data provider. This is done here: betalingsservice.dk/erhverv/få-hjælp/form-skift-dataleverandør
In the comment field, request adjustments for any settings found in step 1 that were incorrect, for example:
1) 603 deliveries must be enabled: We want both daily sign-ups and cancellations (0231, 0232, 0233, 0234) as well as monthly delivery (0230).
Automatic payments should be notified on the payment date.
We want electronic notifications of rejections/refunds for automatic payments on an ongoing basis.
We want to import 605 files submitted by our data provider.
3. Same day as step 2
Iteras, together with you, checks with your bank whether notification via Betalingsservice is enabled on the correct FI numbers.
4. The day before the conversion window opens
A 603 file is requested from Betalingsservice. This file contains all existing BS agreements. It will be ready the next morning. It is ordered the day before to ensure we capture as many BS agreements as possible (and to prevent new agreements from being created between when we receive the file and when we convert the agreements).
5. Same day as steps 2 and 3 are confirmed
Iteras deposits DKK 0.01 into each FI number. Two days later, we should be able to see in Iteras that the amount has been registered, meaning that the entire chain is working as intended (amount credited to the account, account notifying BS, BS notifying Iteras).
6. Same day as step 2 is confirmed AND the conversion window has opened
Iteras submits a 605 change file to BS, converting BS agreements from Nav subscription numbers to Iteras customer numbers.
7. The day after step 6 is confirmed
Iteras checks with BS (via the online portal or by phone) that the conversion was successful. If not, the issue is investigated, and another attempt is made. BS requires 1 day to process each attempt.
8. Two days after step 5 is completed
Check that the 2 × DKK 0.01 transactions are registered in Iteras. If so, invoicing via Betalingsservice can begin, and the conversion is complete.