Purposes / New Head per Entry / Max. Pos. Payment Note

The fields "New Head per Entry" and "Max. Pos. Payment Note" always refer purely to the number of items and there is no direct reference to the note to payee lines. Header and footer lines that may have been set up are not taken into account here and can cause the note to payee to be insufficient.

Since all calculations refer to entry-level and are not linked to each other, both fields - "Max. Pos. Payment Note" and "New Head per Entry" - are evaluated independently of each other. Here, logical attention should be paid to how the setups are made.


Max. Pos. Payment NoteNew Head per EntryMax. Pos in Cust. / Vend.Result
00201 head with 20 entries (payment note by limitation from the system)
50201 head with 20 entries (payment note by setup) from the 5th entry onwards
05204 heads with 5 entries each
012020 heads with 1 entry each
1010202 heads with 10 entries each incl. payment note
1110202 heads with 10 entries each without payment note
1011202 heads: 1 head with 11 entries and payment note 1 head with 9 entries without payment note

In case you have made a setup for which the existing note-to-payee lines are not sufficient, there is a safety mechanism in the payment export in the form of a warning message that signals that not all entries in the purpose can be displayed.

This problem often occurs using the placeholder "@" within the payment types for concatenation.

Example: A payment proposal for 12 entries is generated for a customer. In the payment type "Max. Pos. Payment Note" = 14 is set up. In addition, the " Customer Purpose Text " is very long because "@%1 %2 %3 %4 %5" has been set up here.

However, this problem can also occur when working with very long (ext.) document numbers and only the placeholders "%1 Document No.", "%2 Payment Amount", "%3 Pmt. Discount Amount" are set up.

Payment proposal error

During concatenation, all documents are written to the lines one after the other. No care is taken to ensure that the values remain logically linked. If necessary, the document numbers are separated and continued in the next line of the purposes.

In this processing, however, there is the advantage that even more entries can be handled via the purpose before the system would have to create a payment note or a new header.


line 1Document 1| Document 2| Document 3
line 2| Document 4| Document 5| Document 6
line 3| Document 7| Document 8| Document 9
line 4| Document 10| Document 11| Document 12
line 5| Document 13| Document 14|…


line 1Document 1| Document 2| Document 3| Document 4
line 2| Document 5| Document 6| Document 7| Document
line 38| Document 9| Document 10| Document 11|Do
line 4cument 12| Document 13| Document 14|…

The standard processing for SEPA purposes is as follows:

  • In the first place the value "Our Account No.". (if stored on the person account) is entered. After that, the document numbers are filled up one after the other, as the following example shows. This default setting can be overridden at any time.
Line 1ABCDEF/00001, 00002, 00003, 00004,
Line 200005, 00006, 00007, 00008, 00009,
Line 300010, 00011, 00012, 00013, 00014,
Line 400015, 00016,

ABCDEF = our account number

00001 to 00016 the document numbers concatenated

If you do not want such a display, you can change it accordingly with placeholders in the respective payment type, as already described above. As placeholders you have the following options for the reason for purpose lines:


As a placeholder, you have the following options for the purpose headers:


For all payment types that have more than 2 and less than 10 purpose lines, automatic document chaining will be performed unless you have set something else up.

Number of available purposes


Alt. Reason Code in Customer / Vendor Bank Account

The alternative purposes from the customer/vendor bank account card can optionally be combined with the entry-related purposes described above.

If a "+" sign is entered in the first place in the bank account purpose in line 1 or line 2, the purposes will be combined. I.e. first the first two lines from the bank account card are created, if necessary, and then the remaining lines are created in the same way as usual for creating the purpose.

This is illustrated by the various setups:

For example, two "Alt. Reason Rows" are stored on the bank account (in the bank account card):

Alt. reason rows

Result in the purposes after creating a payment proposal in the payment proposal card:

Alt. reason rows

A linked setup with the entry-specific uses would be performed as follows:

Alt. reason rows

There is then a link between the Alt. Reason Row 1 of the bank account card (red) and the defined line-related purposes (green):

Alt. reason rows

Provide uses beyond the line

If, for example, %1 %11 %6 %9 is entered in the placeholder of the payment type, the text for a single item may not be sufficient per line. 4*35 lines are provided. Now, if more than 35 characters are set for one line (as in this example setup), the purposes will be truncated and not continued in line 2. Thus, it can be said that in this type of setup, a setup line always refers to a purpose line.

However, it is possible to set it up so that the line breaks automatically and the text continues in the next line. For this function, another placeholder is available: "^". You can view this via the AssistEdit:

Alt. reason rows

For example, setting up a payment type could look like this:

Alt. reason rows

For example, the result within a payment proposal would be as follows:

An entry with little text is marked (green area).

Entry with little text

A second entry with more text is highlighted (blue area):

Entry with more text

The third entry with more text is marked (red area).

Entry with more text

If the available space is then no longer sufficient, as is the case here with the fourth entry (purple area), you will be shown a corresponding warning message.

Entry with more text

Entry with more text