Direct Remittance User manual

Transcription

1 Direct Remittance User manual Version 5.1 Dato Page 1 of 24

2 Contents 1 Introducing Direct Remittance... 3 Brief overview of the service... 3 Why direct remittance?... 3 Benefits for companies... 3 Formats and restrictions In-depth service description... 4 BBS format... 4 Telepay format... 5 ISO format Agreement handling with direct remittance... 7 Create an agreement on the use of direct remittance... 7 Changing an agreement... 7 Termination of an agreement... 7 Invoicing for direct remittance Transfer of customer ID (KID) Transmissions from Nets... 8 Notification of a credit to a payee... 8 Transmissions from Nets... 9 Text on account statements to payees Giro payment Incorrect settlement of task Testing direct remittance Internally developed accounting system System specification test Data communication between the data sender/payer and Nets Operating direct remittance (DIRREM) Operating pattern for DIRREM Check on receipt and validation Accounting data Renumbering Corrections/deletions Settlement checks with the payer Receipt lists Receipts for BBS format Recommended processing of receipt lists by the payer Change log Page 2 of 24

3 1 Introducing Direct Remittance Brief overview of the service Direct remittance is an electronic payment service. When the company registers incoming invoices and makes salary payments, the payment transactions are sent to Nets in a file. Payment transactions can be sent for various transaction types. The file can be sent directly to Nets, via another data centre or via the bank. Upon receipt at Nets, the payment transactions will be placed on a register of due payments until the payment date, which can be a maximum of 12 months in advance. If required, a summary of settled transactions may be sent to the company as accounting data so that the subsidiary ledger can be updated automatically. Companies that make submissions in Telepay or ISO format will receive settlement refunds in a file. Before the service can be used, an agreement must be set up between the company and the bank. Why direct remittance? The majority of salary and accounting programmes are set up to allow direct remittance, so in most cases the service can be used with minimal adjustments. The service is suitable for customers who are seeking an effective solution for bulk payments and who do not wish to be dependent on any bank. Using direct remittance allows the company to avoid the manual work involved in paying salaries and invoices. Benefits for companies Using direct remittance allows the company to avoid the manual work involved in paying salaries and invoices. The company gains optimal liquidity management in that all payments are carried out on the payment date so no interest is lost through early or late payment. If the company has many invoices and, perhaps, credit notes from the same recipient, these can all be sent as one total. This means further savings on the costs of the transactions. Formats and restrictions Companies that opt to use direct remittance can submit files in BBS, Telepay or ISO formats. Companies that use direct remittance may only have one agreement per task account. The agreement may be registered with a bank or with Nets. For customers who make submissions in Telepay or ISO formats, there are some restrictions regarding what we can process in terms of transactions. We process only salaries, bulk payments and invoices, with a message, credit note and customer ID, and only in NOK. Page 3 of 24

4 2 In-depth service description BBS format Agreement verification Shipment from issuer Recieve file Receipt L226 created. Validation of request. Receipt 202 created. Due date registry 6 4 NICS Transaction sent to settlement. Balance control Receipt L1002 Request rejected in balance control created Accounting data bank Accounting data customer Payer s bank 1. The payer/data sender sends the data to Nets, and receives receipt L Nets checks the files received and sends the data sender receipt lists for the transmissions that have been input. Any errors in tasks are reported to the recipient of the list in the form of list L The transactions are updated on the register of due payments at Nets. 4. On the due date, the transaction tasks are sent to the bank for a check on available funds. 5. Any tasks rejected by the bank during the check on available funds are reported on receipt L1002 and sent to the recipient of the list. 6. The transactions are sent for settlement. Alternatively: a) notification of a credit is sent to the recipient; b) a Giro payment is sent to the recipient. 7. Accounting data for the bookkeeping of the payer s bank account and the credit to the payee s bank account are sent to the banks and the banks data centres on the same day that settlement takes place at Nets. Aggregate amounts for the settled sub-tasks will appear on the bank statement that the payer receives from their bank. The amount may appear on the recipient s account statement with: a reference to the payer s agreement ID at Nets; fixed text as indicated in the direct remittance agreement; an external reference in the individual transaction. If the payee s account number is not known to the payer, Nets can send a Giro payment to the payee. This must be indicated on the task to Nets in the case of special transaction codes, and the name and address of the payee must always be provided. If the account number is incorrect and the transaction contains a name and address, Nets will automatically send a Giro payment to the payee. 8. If this has been agreed, the payer can receive accounting data, which is a breakdown of approved/settled transactions. When a transfer is made into the payee s account, the payer can choose whether or not Nets should inform the payee that the amount has been transferred. If Nets is to inform the payee, the payee s name and address, together with a breakdown where applicable, must be indicated in the task to Nets. Page 4 of 24

5 Telepay format Agreement verification Shipment form issuer Receive file File validated. Validation file R1 created. Due date Diue registry date registry 5 4 NICS Transaction sent to settlement. R2-file created. Balance control 6 7 Accounting data bank Settlement response. Receipt R2 created. Payer s bank 1. The payer/data sender sends the data to Nets. 2. Nets validates the file. Validation file R1 is created. 3. The transactions are updated on the register of due payments at Nets. 4. On the due date, the transaction tasks are sent to the bank for a check on available funds. 5. The transactions are sent for settlement and file R2 is created. 6. Accounting data for the bookkeeping of the payer s bank account and the credit to the payee s bank account are sent to the banks and the banks data centres on the same day that settlement takes place at Nets. Aggregate amounts for the settled sub-tasks will appear on the bank statement that the payer receives from their bank. The amount may appear on the payee s account statement. 7. The payer receives accounting data, which is a breakdown of approved/settled transactions. When a transfer is made into the payee s account, the payer can choose whether or not Nets should inform the payee that the amount has been transferred. If Nets is to inform the payee, the payee s name and address, together with a breakdown where applicable, must be indicated in the task to Nets. Receipt file R2 with settlement refund is created. Page 5 of 24

6 ISO format Agreement verification 1 Shipment from customer Recieve file 2 Syntaxcontrol of file. PAIN.002 file created. 3 Validation of file. PAIN.002 «Rejected transactions» file created. 6 4 Transaction sent to settlement. Due date registry 7 5 NICS Transaction rejected at due date. PAIN.002 file created. Balance control 8 9 Accounting data bank Settlement response. CAMT.054 file created. Payer s bank 8. The payer/data sender sends the data to Nets. 9. Nets carried out syntax checking of the file. The file PAIN.002 is created. 10. Nets validates the file. PAIN.002 is created for rejected transactions. 11. The transactions are updated on the register of due payments at Nets. 12. On the due date, the transaction tasks are sent to the bank for a check on available funds. 13. The transactions are sent for settlement. 14. Any tasks rejected by the bank during the check on available funds are reported in the file PAIN Accounting data for the bookkeeping of the payer s bank account and the credit to the payee s bank account are sent to the banks and the banks data centres on the same day that settlement takes place at Nets. Aggregate amounts for the settled sub-tasks will appear on the bank statement that the payer receives from their bank. The amount may appear on the payee s account statement. 16. The payer receives accounting data, which is a breakdown of approved/settled transactions. When a transfer is made into the payee s account, the payer can choose whether or not Nets should inform the payee that the amount has been transferred. If Nets is to inform the payee, the payee s name and address, together with a breakdown where applicable, must be indicated in the task to Nets. Settlement refund CAMT.054 will be created. Page 6 of 24

7 3 Agreement handling with direct remittance Create an agreement on the use of direct remittance Use of the direct remittance service requires an agreement to be entered into between the payer and the payer s bank. The bank can register the agreement itself on Nets Online, or send the registration form to Nets for registration. If the agreement is to be sent to Nets, the registration form must be sent in PDF format to the following address: payment-test-no@nets.eu. When the agreement has been registered, the payer and the bank will receive an containing information about when the agreement will be ready for use. If the data sender or data recipient is not already registered with Nets and is not the agreement customer (e.g. an accounting firm), a separate agreement must be set up. For information on your own data sender, data recipient and list recipient, contact Nets Customer Services on or by payments-no@nets.eu. Information about internal data senders etc. will be assigned its own customer unit ID that will identify the accounting office and who sends and receives data for the various task accounts. Additionally, all receipt lists associated with the same customer unit ID that receive postal transmission will be sorted and grouped together so that all lists are sent to the accounting office. Customers who receive lists by will be sent the lists shortly after the task has been processed. An invoicing account must be linked to the customer unit ID. If the accounting firm is already a customer, it is not necessary to set up a separate agreement. Once the agreement has been registered, Nets will send an to the payer and the bank stating that the agreement has been registered and is ready for use. Changing an agreement In the case of a change of bank account, a new agreement must be created for the new account. The old agreement should not be terminated or deleted until all transactions on the register of due payments have been settled. If the old agreement is retained, tasks on the register of payments due will not be affected but will be charged to the new account. When accounts are changed, a decision must be made as to whether the transactions that are due to be paid should be settled against the new or old account. If the transactions are to be settled against the old account, the account change date must fall after they have been settled. When changing bank account, the old account number must be stated on the new agreement. The agreement should be sent to Nets by payment-test-no@nets.eu. If the data sender is to be changed at the same time as the account is changed, the new data sender ID must be given on the agreement. Termination of an agreement The bank may terminate the agreement via Nets Online. If the bank wishes Nets to do this, Nets must be sent a written notification of the termination of the agreement from the bank. The termination should be sent to paymenttest-no@nets.eu. Page 7 of 24

8 Invoicing for direct remittance Invoicing for direct remittance is a matter dealt with between the payer and the payer s bank, and any questions regarding price/invoicing should be taken up with the bank. 4 Transfer of customer ID (KID) Payers of direct remittances enjoy a major advantage when paying an OCR Giro that they have received. See the example below, which shows a Giro that contains the customer ID. Generally, the banks will charge a lower price for transactions by direct remittance using the customer ID than for direct remittance with a message. Check whether or not it is possible to register customer IDs in your accounting package, or speak to your software supplier. The payee will then base the update to its subsidiary ledger automatically on accounting data from Nets. If the customer ID is used in the direct remittance transaction, the payee avoids having to register the incoming payments manually. This allows faster updating of the subsidiary ledger. NB: In direct remittance transactions where the payee has a mandatory customer ID agreement, a customer ID that is incorrect according to the agreed modulus and length will lead to the transaction being rejected on receipt. For BBS format, the payer will receive documentation of rejected transactions in the form of list L00202 with the text «Recipient requires a customer ID». With Telepay or ISO formats, the customer will receive a return file detailing the rejected transactions. 5 Transmissions from Nets Notification of a credit to a payee Notification of a credit from Nets When Nets is to send notification of a credit to the payee, the payee s name and address must be specified on the transaction record sent to Nets. Page 8 of 24

9 5.1.2 Design of the form Notification of a credit contains the name and address of the payer on the front, together with the amount to be credited to the account. If any text for the payee has been added to the transaction record, this will appear on the form. In the text specification, a maximum of 42 lines may be entered, divided into two columns of 40 positions each and with 21 lines in each column. The Nets date, the payee s account number and the amount will also be shown. Transmissions from Nets A transmission may contain notifications from the various electronic services within the same envelope. Each envelope has an address card on which the content is specified. The bottom line on the form s reverse side will always contain the date, amount and form number, identical to the front side. Giro payments will always be sent in a separate envelope and by post. It is possible to choose alternative channels to postal dispatch. By using other channels, there is the option for more rapid monitoring and updating of the subsidiary ledger. The recipient of the notification must enter into an agreement with their own bank regarding alternative modes of dispatch, e.g. by or NettPost. Page 9 of 24

10 Text on account statements to payees Messages identifying the transaction/payer can be placed on the payee s account statement. Fixed text: The payer may specify in the direct remittance agreement a fixed text (max. 25 positions), which will be placed on the payee s account statement. If fixed text has not been set out in the agreement, Nets will automatically put the name of the agreement in this field. Giro payment Giro payments have a separate specification section where messages can be left for the payee. In the specification section, a maximum of 42 lines may be entered, divided into two columns of 40 positions each and with 21 lines in each column. See the example of a Giro payment below Processing transactions with missing information: If the mandatory name and address of the payee are missing from a transaction for Giro payment, the transaction will be rejected on input at Nets. For BBS format, rejected transactions are specified for the payer on error list L For Telepay and ISO formats, rejected transactions will be sent back in a file. It is not possible to send Giro payments abroad. If the transaction contains a foreign address, it will be rejected on receipt at Nets. If the recipient s account number is not CDV-valid, Nets will automatically generate a Giro payment. In such instances the mandatory name and address records must be given for the transaction. Nets will reject the transaction if the name and address records are missing or contain a foreign address. Incorrect settlement of task Once settled, according to the Norwegian Financial Contracts Act tasks/individual transactions cannot be returned by the payer. Exceptionally, the bank/nets may perform a chargeback within three days in the event of an internal operational deviation. Where the Act prevents such a refund from being made, there is still the option of having the amount returned according to the normal regulations, i.e. by raising a claim against the account holder in question. Page 10 of 24

11 6 Testing direct remittance Internally developed accounting system Payers/data senders who have their own internally developed systems may themselves develop the necessary programs to use direct remittance. If the payer uses a software supplier/data centre, a check should be performed to ensure that everything within the service is provided in the software package. System specification test A production test must be performed and approved by Nets in good time before entering production. No test is required if the payer uses an approved ERP supplier/accounts office for Nets services. A separate agreement for the data sender must be registered with Nets. Data communication between the data sender/payer and Nets Before the test commences, communication must be established with Nets. This can be done by contacting the Test Group.The Test Group can help with testing, materials and data communication. Enquiries can be directed to Customer Testing by payment-test-no@nets.eu or telephone The data sender/payer can use a variety of channels to send the transmission to Nets, for example, by sending directly to Nets or via an ERP supplier. The communication solutions currently available are as follows: Customer portal sftp Nets posts the accounting data and settled transactions in accordance with the agreement made with the bank. The data sender/payer can retrieve this via the communication method set up. Below is a point by point description of how testing is performed at Nets. Any questions should be directed to Customer Services, who can be contacted by telephone: or by payments-no@nets.eu Testing of BBS format Test files are sent to Nets via proprietary software or the ERP supplier for all transaction types to be used in production. Test files from Nets are delivered in accordance with the agreement, if desired. Once testing is complete, Nets will contact the customer with notification of the results of the test. If necessary, a further test will be agreed upon. When the testing has been completed and approved, the bank and the customer will receive an stating that the agreement has been registered and is ready for use Testing of Telepay format Test files are submitted to the agreed test ID. The test files must include the transaction codes the customer wishes to test. The customer will receive two receipts in a file. The first receipt will specify whether the file was rejected or approved, whilst the second receipt will contain settled and cancelled tasks. When the testing has been completed and approved, the bank and the customer will receive an stating that the agreement has been registered and is ready for use. Page 11 of 24

12 6.3.3 Testing of ISO format Before the customer carries out testing with Nets, they must carry out the format validation provided on the BITS website: Test files are submitted to the agreed test ID. The test files must include the transactions the customer wishes to test. The customer submits the test files in PAIN.001 for the transactions. When deleting transactions, the customer submits the file with CAMT.055. The customer will receive a receipt in file PAIN.002 for rejected transactions, whilst settled transactions will be sent in CAMT.054. For deletions, receipts will be received in CAMT.029. When the testing has been completed and approved, the bank and the customer will receive an stating that the agreement has been registered and is ready for use. 7 Operating direct remittance (DIRREM) Operating pattern for DIRREM Data submission deadlines Submission deadlines for processing of submitted files are in accordance with the general operating pattern, which can be found at Settlement/check on available funds Transactions are settled at Nets during the first possible settlement on the same working day as the specified payment date. If the specified payment date is not a working day, Nets will use the next working day as the payment date. Transactions are processed in accordance with the operating pattern that can be found at Transactions where the specified payment date is 12 months prior to the current date will be settled on receipt at Nets. The values of transactions will not be backdated. Checks on available funds will be performed on the account being debited prior to each settlement. Nets must have written notification from the bank/payer if a task is to be reopened once it has been rejected during the check on available funds. A task can be reopened up to 40 calendar days after the due date. If the task is to bypass the check on available funds, written notification must be sent from the bank. Notifications can be sent to the Authorisation Group at payment-no@nets.eu Register of due payments at Nets Payers have the option to enter tasks onto the register of due payments up to 12 months in advance. Check on receipt and validation Check on receipt for file transmissions Checks are performed to ensure that the file/data sender is registered with Nets and has full authority to send data on the specified customers with an agreement/payment account. Page 12 of 24

13 If the customer with the agreement/payment account changes the file sender/data sender, the customer s bank must be informed of this. All file transmissions to Nets are checked before input. Errors in the file transmission will result in the file being stopped. There are various possible reasons for this: invalid file/data sender; transmission file is not in a valid format; empty transmission file. For Telepay and ISO formats, rejection messages will be sent in a file. If the agreement entails use of BBS format, the error message will be documented on receipt list L200, which will be posted in the customer portal Checking transmissions received at Nets Transmissions that are received at Nets will be checked both at transmission and task level, prior to processing. Following these checks on the transmission, receipt L226 is produced. L226 is posted in the customer portal or sent by if BBS format is used. For ISO and Telepay formats, the customer will receive a receipt in a file. For ISO format, they will receive PAIN.002 and for Telepay R2. The recipient of the receipt list must immediately check whether the transmission has been approved or rejected Duplicate check/rejection check For transmissions containing tasks in BBS format, Nets will check to ensure they have not already been processed. The checks are performed on the entire content of the transmission, including all tasks. A check is performed on the previous 12 months + 1 day to ensure the task has not already been processed. For ISO, duplicate checks cover three months. For Telepay, the sequence number and sequence check field must agree. The following are checked at transmission level for BBS format: that the file/data sender is able to send on behalf of the payment account; that the transmission has not already been imported; that Nets is the recipient; that the start record of the transmission is correct; that the start record of the task is correct; that the amount specified in the end record of the transmission is correct. A check is performed to ensure that the total in the end record of the transmission matches the end record in the task, or the total of all amount transactions in the task, and that: the agreement has been correctly registered; the transmission contains the correct number of transactions; the transmission contains valid tasks. For ISO format, a syntax check is carried out for the transmission. The following are checked at task level for BBS format: that there is a valid agreement for the service; Page 13 of 24

14 whether the task has been imported and processed earlier. The check goes back 12 months + 1 day from the current date; that the start and end record of the task are present and correct; that the transactions in the task are valid; the number of transactions in the task; the number of records in the task; the first date in the last task item; the last date in the last task item; that the aggregate amount in the total record of each task does not exceed the maximum possible total amount (see system specification). For ISO and Telepay formats, the entire content of the file will be subject to validation. Accounting data Accounting data for the payer If the payer wishes to receive accounting data, this must be specified in the direct remittance agreement. Accounting data is a breakdown of approved, settled transactions. Settled transactions can be submitted for one or more of the following times: Morning settlement Intermediate settlement no. 2 Intermediate settlement no. 3 Final settlement If there is an agreement in place regarding use of several services (e.g. OCR or Autogiro), the accounting data will be sent compiled in one file according to the agreed schedule. Nets can offer the following schedule for the transfer of accounting data: Daily Weekly times per week any days Monthly times per month any days Quarterly - On the last day of the quarter The timings for access/transfer of files will be in accordance with the operating pattern. The aggregate amount debited to the account can be found on the account statement from the bank. Example: Direct remittance tasks sent by am and approved in the check on available funds by 1.00 pm will be settled and reported in the afternoon settlement run and sent in the accounting data by 3.00 pm. If the funds in the account are insufficient to cover the aggregate amount to be debited, the task will be sent for a further check on available funds (a maximum of five times). Note: If you do not receive accounting data in BBS format, the settled tasks must be processed manually in the subsidiary ledger. Nets keeps a backup of accounting data for 90 working days. Page 14 of 24

15 7.3.2 Receipt of several accounting files Receipt of several accounting files on the same day will result in changes for the individual bank customer/bank. Bank customers who download files manually via Nets will see several instances of files with the same date ready to download. These files will be marked with different letters indicating the particular settlement run. Bank customers with automatic transfer via FTP must contact Nets to create new file names before receiving accounting data from multiple settlements. This can result in changes in the bank customer s procedures and must be clarified before amending the agreement. The Nets Test Group can be contacted by at: payment-test-no@nets.eu for coordination purposes. If the bank customer wishes to change the time of delivery of accounting data, confirmation can be ed to the customer s bank or Nets at: payment-test-no@nets.eu. The must include the company s business registration number, customer unit ID and account number. Technical arrangements between the bank customer/bank and Nets are taken care of by the Nets Test Group when the individual agreement is received. Nets offers accounting data for those payers who wish to carry out automatic updating of their subsidiary ledgers. Accounting data is a breakdown of approved, settled transactions. Renumbering All transactions received by Nets are checked against the renumbering register at Nets. Renumbering will take place if the payee s account exists on the register. It is not possible to send Giro payments of amounts exceeding NOK 99,999, million. If this limit exceeded it will be reported on L00202 with the message: THE AMOUNT ON THE INSTRUCTION IS TOO LARGE. For BBS format, this is reported on receipt list L00202 Rejected tasks/transactions. For ISO and Telepay formats, this is reported via a file. Corrections/deletions Corrections/deletions can be performed on individual settled transactions on the Nets register of payments due. For ISO and Telepay formats, deletions must be submitted in a file. Manual corrections are not possible with these formats; only deletions may be carried out. If BBS format is used, a correction form must be used. You will find it in The following changes can be made to an individual transaction: reduction of an amount; deletion of a transaction; change to a payment date. The correction form should be sent to the Nets Authorisation Group by payment-test-no@nets.eu The Customer service can also be contacted by telephone: Note: Only tasks that have not been settled can be deleted. Page 15 of 24

16 Settlement checks with the payer The payer has a responsibility to ensure that the necessary internal checks are performed so that any incorrect processing of transmissions, tasks and transactions can be discovered immediately. Nets recommends that payers have a subsidiary ledger system, provided by the software supplier/data centre for the automatic updating of transactions. As a foundation for the automatic updating of the subsidiary ledger, Nets offers accounting data that specifies all approved, settled transactions. Updating the subsidiary ledger on the basis of submitted data is not recommended. Updates should not be made before settlement as transactions may be rejected at input. For BBS format, receipt list L00202 from Nets must be checked and any transactions rejected/carried out again specified on the error list must be processed manually in the system. For Telepay and ISO, all rejections and settled transactions will be sent in a file, which must be processed by the payer. Page 16 of 24

17 8 Receipt lists The receipt lists described below apply only if the agreement entails use of BBS format. If the agreement entails use of ISO or Telepay formats, the receipts will comprise files uploaded to the file mailbox for the customer. Receipts for BBS format The following lists are produced for BBS format: L200 L226 Receipt list of rejected transmission files. This receipt will be generated in cases where the transmission file is not in Nets format, the transmission file is empty or the data sender is invalid. The receipt will be posted in the customer portal. Receipt for input transmissions. Documents all approved and rejected transmissions. This receipt is made available on enett immediately once the transmission has been sent to Nets for downloading by the data sender, who must check whether the transmission has been approved or rejected. Alternatively, the receipt may be sent by to the data sender or the customer with the agreement. The lists below are sent by . If Nets does not have a registered address for the customer, the receipts will be sent by post. L00202 L01002 L01003 Receipt for changed and rejected transactions/tasks DIRREM Receipt for deviating transactions and tasks DIRREM. Documents tasks for repeat payment and those rejected in the check on available funds. Transactions rejected due to an invalid customer ID. Receipt for changes in transactions and tasks DIRREM. Documents corrections to tasks, sub-tasks and transactions carried out on the pending register L200 RECEIPT LIST OF REJECTED TRANSMISSION FILES 1) Data sender ) Input date 25/04/2014 3) Status after input REJECTED 4) Error messages Empty transmission file: Explanation: 1. File/data sender 2. Nets input date 3. Status REJECTED 4. Error message Page 17 of 24

18 8.1.2 L226 RECEIPT LIST OF IMPORTED TRANSMISSIONS 1) Data sender NETS NORWAY AS NETS NORWAY AS Address C/O ACCOUNTS Town: 0978 OSLO 2) Data sender given in the transmission NETS NORWAY AS NETS NORWAY AS Address C/O ACCOUNTS Town: 0978 OSLO 3) Transmission number Input date 4) 25/04/2014 5) Status after input APPROVED Number of transactions Amount Specified 69 6) Imported Difference ) Direct remittance tasks: Number of tasks registered 1 Number of tasks approved 1 Number of tasks rejected 0 7) AvtaleGiro: Number of tasks registered 0 Number of tasks sent for processing 0 Number of tasks rejected 0 7) Autogiro: Number of tasks registered 0 Number of tasks sent for processing 0 Number of tasks rejected 0 Page 18 of 24

19 7) Securities trading: Number of tasks registered 0 Number of tasks sent for processing 0 Number of tasks rejected 0 7) Other tasks: Number of tasks rejected 0 8) Error messages Nets will check the transmissions when they are imported. If any errors or deficiencies are discovered in a transmission this may lead to the entire transmission being completely rejected. One or more tasks in a transmission can also be rejected. The number of tasks sent for processing is not checked in its entirety and may be rejected when all the content is validated. Rejected tasks and transactions are documented in receipt L Data senders/customers who receive this receipt after the file has been sent must check whether the transmission has been approved or rejected. If the transmission has been rejected, the reason must be documented and the file re-sent. Explanation: 1. File/data sender 2. Data sender specified in the 10 record (transmission start record) 3. Transmission no. specified by data sender 4. Date input 5. Status indicating whether the transmission has been approved or rejected 6. Aggregate amount of those approved/rejected in the transmission and, where applicable, the difference 7. Service and number of tasks in the transmission 8. Any error messages Page 19 of 24

20 8.1.3 L00202 RECEIPT FOR CHANGED AND REJECTED TRANSACTIONS/TASKS DIRREM Below is an example of receipt L00202: The header contains the list name and the input date of the tasks. The first section contains information about the customer and task: customer ID/business registration number, unique payer ID, followed by name; agreement ID, unique ID for the agreement, followed by agreement name; data sender and transmission number; task number, unique task ID, followed by payment account, account to be debited; the status after input will indicate whether the task has been approved or rejected: Tasks with the status APPROVED have been imported into Nets, but the following table will show rejected transactions or other error messages in the task. Transactions not stated in the table have been approved without changes and will be settled; Tasks with the status REJECTED are stopped in the import check. All transactions have been rejected and the task must be resubmitted. The table gives an overview of changed and rejected transactions. The footer contains the list number, name of the recipient of the list and the number of pages. Page 20 of 24

21 8.1.4 L01002 RECEIPT FOR DEVIATING TRANSACTIONS AND TASKS DIRREM Below is an example of receipt L01002: The header contains the list name and the date on which settlement of the task was attempted. The first section contains information about the customer and task: customer ID/business registration number, unique payer ID, followed by name; agreement ID, unique ID for the agreement, followed by agreement name; payment account, account to be debited. The table gives an overview of the tasks and transactions rejected at settlement. The footer contains the list number, name of the recipient of the list and the number of pages. The list shows tasks/sub-tasks sent for repeat payment or rejected in the check on available funds. If a task/sub-task has been rejected in the check on available funds, the payer may resubmit the task with a new transmission no. and task no. The payer can also contact the bank or Nets to have the rejected task settled again. A written request must be sent to the Authorisation Group at Nets from the bank or payer. If the task is to bypass the check being performed on available funds, written confirmation of this must be sent from the bank to authorisation-no@nets.eu Page 21 of 24

22 8.1.5 L RECEIPT FOR CHANGES TO TRANSACTIONS AND TASKS DIRREM Below is an example of receipt L01003: The header contains the list name and the date the change was carried out. The first section contains information about the customer and task: customer ID/business registration number, unique payer ID, followed by name; agreement ID, unique ID for the agreement, followed by agreement name; payment account, account to be debited. The table gives an overview of tasks and transactions that have been changed. The footer contains the list number, name of the recipient of the list and the number of pages. The payer can perform corrections/deletions on unsettled transactions on the holding register at Nets. A task that has not been settled may be changed or deleted. Corrections performed are indicated on the list. Page 22 of 24

23 Recommended processing of receipt lists by the payer Payers process the receipt lists for direct remittance in a variety of different ways. We recommend checking the following points when taking receipt of receipt lists L200 Receipt for input transmission file Sent to the data sender in the event of an error message: invalid file sender, transmission file is not in Nets format and empty transmission file L226 Receipt list of input transmission Check status after input Transmissions and approved amounts match submitted data In the event of an error, contact the Authorisation Group at Nets immediately L00202 Receipt list of changed and rejected transactions/tasks DIRREM This receipt list will be produced ONLY in the event of a discrepancy. The receipt documents rejected tasks and transactions. The receipt will also report any transactions carried out again or other information on errors that did not lead to rejection. It is sent out by shortly after the task has been processed. Lists sent out by post are bundled together and sent out once a day. The list must be checked so the customer can look into rejected tasks/transactions further. It is important to check the status of the task as the task may have been rejected L01002 Receipt for deviating transactions and tasks DIRREM in the check on available funds. This list documents tasks sent for repeat payment and that have received a final rejection in the check on available funds. The list will be sent out after every settlement to those who receive the list by . This will give customers the opportunity to make a transfer from another account, if desired, so that the task is not rejected. The check on available funds will be attempted five times. If the funds in the account remain insufficient, the file will be rejected. Lists sent out by post are bundled together and sent out once a day. The payer must check the list and consider how to proceed with the task L01003 Receipt for changes to transactions and tasks DIRREM List of information showing the number of corrected tasks, sub-tasks and transactions. Check whether the list matches the copy of the list of submitted corrections. The list will be created and sent out shortly after the correction has been carried out, for those customers who receive the list by . Lists that are sent out by post will be bundled and sent out once a day. Page 23 of 24

24 9 Change log VERSION SECTION DESCRIPTION OF CHANGE DATE SIGNATURE 5.0 Documentation reviewed and revised 30/01/2017 wme 5.1 Deleted correction form, new logo 10/09/2018 wme Page 24 of 24