Versions Compared

Old Version 5

changes.mady.by.user PAYONE Writer

Saved on

compared with

New Version Current

changes.mady.by.user PAYONE Writer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Payments Assignment

Introduction

With account-based payment methods such as advance payment, invoice and direct debit, the incoming payments have to be assigned to the appropriate payment processes on an account.
The assignment of the payment from the receipt of the payment to the payment process largely takes place automatically on the PAYONE platform on the basis of a calculated scoring which is, among others, based on the name of the account holder, the amount of the incoming payment, and the account data provided by the bank. If it is possible to clearly find a payment process with the data which is provided on the account statement, and if an incoming payment is still expected there, then an automatic assignment takes place.

If the payment process has already been settled and no further incoming payment is therefore expected, or if no data was found in the account statement which enable a clear allocation then a manual assignment of the incoming payment is required. This manual assignment is initially completed by specially trained PAYONE employees. If it is not possible to make a clear link between the incoming payment and the payment process here, then an email enquiry is sent to the merchant with the request to provide notification as to whether and/or how this incoming payment is to be entered.

With the assignment of the payment in the PMI, it is now possible for the merchant to assign an open payment process independently if a manual assignment by PAYONE itself is not possible. The payment process is set to "Clarification by the merchant" by PAYONE and is therefore visible in the payment assignment in the merchant's PMI. The merchant can now look for a suitable payment process in the PMI and assign the incoming payment themselves accordingly.

UI Text Box
typewarning

If an incoming payment belongs to an end customer's payment process and the end customer in question is not allocated then the payment process remains open and moves across to the dunning run and the collection order.

Overview of the Open Incoming Payments

Section


Column

You can find the assignment of payments in the PMI in the main navigation menu:


UI Text Box
typeinfo

In the working area of the PMI, the open incoming payments which have been assigned to you for manual assignment are now displayed. 



Column



Section


Column


Column

If you use several accounts then a selection list appears under (1) with which you can switch between the accounts. You can filter the incoming payments according to the current status (see below) under (2). You can limit the time frame and the status of the incoming payments under (3). Underneath it you will find a listing of the incoming payments which you can subsequently open individually, and to which you can assign the corresponding payment processes in succession.


The following fields are shown:

Statement number/item

Number of the account statement and the item

Process

Entry text from the account statement, here is a list of the most frequent entry texts The entry texts are not standardised and are determined individually by every bank. PAYONE shows the entry text from the account statement – such that it was made available. Should you have any questions, please contact your account-holding bank.:

Text

Description

CASH CONCENTRATING ENTRYTransfer between different primary accounts -> not to be assigned to any payment process
DATA ENTRY. DIRECT DEBIT, DATA ENTRY OF DIRECT DEBIT, DIRECT DEBIT ENTRYCredit entry on the basis of the submission of SEPA direct debit files
-> several payment processes are associated with this credit entry
Received SCT, credit entry, SEPA credit entry, SEPA-CT CREDIT SINGLE ENTRYCredit entry from a SEPA credit transfer
-> is to be assigned to a payment process
SEPA direct debit chargeback, RETURNChargeback from a SEPA direct debit
-> is to be assigned to a payment process


Intended purpose

the first intended purpose field

Entry date

Entry date from the account statement

Name

Name of the account holder – if stated in the account statement

Amount (currency)

the original sum from the incoming payment

Sum

Description

positive Incomingpayment: credit transfer, credit entry
negative Outgoingpayment: debit


Remaining amount (currency)

the original sum from the incoming payment

Advanced Search

The "not allocated" incoming payments from the last three months are shown as standard. With the advanced search feature, you can optionally show the as yet "not assigned" or "already assigned" incoming payments in a time frame that you have selected. The results can also be filtered with a text search via the intended purpose fields A search is supported on the intended purpose fields 1 to 6.

Section


Column


Column

Please note that in German, umlauts are not transferred in account statements – it is therefore necessary to search for "mueller" or "schroeder" instead. The search does not distinguish between upper or lower case letters. of the account statement.


Assignment via Name Search

Once a line from the list of open incoming payments is selected, the details concerning the incoming payment are then shown. Above this display, in the search field (1) you now have the choice of searching for the name or a reference number (your order number). 

Section


Column

The search results are then displayed underneath. In this example, there was only one match during the search for the name The search for the name is flexible with regard to upper and lower case lettering and converts umlauts automatically. A search for parts of a name is not supported. This means it is possible to search for "Schroeder", "Schröder" or "schröder" – but not for "schröd".. After selecting this match (2), the details on the incoming payment are shown and possible matches are highlighted in green. The remaining sum of the incoming payment and the open sum of the payment process match and the name is also of sufficient similarity (Maxime is also known as "Maxi"), which means an assignment of this incoming payment to the payment process that was found can be completed.

In the aforementioned example, the sum of the receivable from the payment process corresponds to the sum of the incoming payment, which means that the entire sum of the incoming payment has to be entered. Therefore, click on "assign" (3) in order to complete the action.

For this purpose, the sum which is to be assigned is entered in the input field on the bottom right. It is possible to choose between entering the total sum from the incoming payment or a partial sum on the selected payment process. 


Column



UI Text Box
typewarning

Only enter payment processes if these are clearly in the direct context of the incoming payment and a clear assignment is to be made.

This process cannot be reversed.


Section


Column

Subsequent to the assignment, this process is summarised briefly once again (1) and removed from the list of open incoming payments (2).


Column


Assignment via Merchant Reference Search

Section


Column

The search for a payment process is also possible via the merchant reference. To this end, the selection is to be made in the "reference numbers" selection list, and your merchant reference entered in the search field (1) The search for reference numbers does not differentiate between upper and lower case letters. The invoice number and the reference of the payment processes are searched. A search for parts of the reference numbers is not supported.. Once the search is complete, a suitable payment process is displayed again. The sum from the incoming payment (2) and the open sum of the payment process also match here, which means an allocation should take place (3).


Column


Assignment with Several Matches

Section



Column

In this example, more than one match was found during the search for the name. Both matches have the same sum, and this sum matches the sum of the incoming payment.

With the second payment process (2), however, no incoming payment is expected any more, as this has already been completed by direct debit. In this example, the incoming payment is to be completed on the incoming payment (1). To this end, this payment process is to be selected, and the assignment is to be carried out as described above.




Column


Defer Assignment/Clarify Internally

Section


Column

The following incoming payment initially has to be deferred and clarified internally. This means that this incoming payment is hidden in the further processing and can be assigned at a later time.


Column



Section


Column

Subsequent to the selection of the payment process, a comment (1) can be made on the incoming payment and the payment can be set to "in clarification" (2). This process is ended with save (3).


Column



Section


Column

With filter according to status (1), in the overview of the incoming payments, it is possible to initialise an overview of the deferred incoming payments: 


Column



UI Text Box
typeinfo

This incoming payment can now be selected again and assigned as described above.

Assignment without

matches

Matches

Section


Column

An incoming payment (3) can be seen as follows which cannot be assigned to a payment process. So that this does not appear repeatedly in the list of open incoming payments, it can be highlighted accordingly on the incoming payment.


Column



Section


Column

After the selection of the payment process, a comment (1) can be made on the incoming payment and the payment can be set to "clarified, but open" (2). This process is ended with save (3).


Column



Table of Contents
outlinetrue
indent2em