import { Callout } from "zudoku/ui/Callout";

# Which entries the extended payment suggestion includes

The rules by which the extended payment suggestion in 365 business Banking selects open entries: due date, blocks, payment method, recipient bank account.

If an invoice is missing from the payment journal after a run, the cause is usually one of the rules on this page. They apply to the [extended payment suggestion](../payment-suggestion.mdx). The standard **Suggest Vendor Payments** is described on [Microsoft Learn](https://learn.microsoft.com/en-us/dynamics365/business-central/payables-how-suggest-vendor-payments).

## Which entries count

| Account type | Document types included | Additionally |
|---|---|---|
| Vendor | Invoice, Credit Memo, Finance Charge Memo, Reminder | no further conditions |
| Customer | Invoice, Credit Memo, Payment, Refund | only entries with a **credit balance** of the customer (negative remaining amount), that is, amounts you owe the customer |
| Employee | all document types | no further conditions |

In addition, each entry must:

- be open with a **Remaining Amount** other than zero,
- meet the template's entry filters and the request page filters,
- belong to an account type that is turned on in the template.

## What is skipped

| Rule | Applies to | Why |
|---|---|---|
| **Due Date** after the **Last Due Date** | vendors, customers | Entries that are not due are included in the next run. Entries without a due date are always included, as are all entries if **Last Due Date** is blank. Exception: with **Find Payment Discounts**, a vendor ledger entry is still included if its payment discount date or payment discount tolerance date is within the period. See [Payment discount](payment-discount.mdx). |
| **On Hold** code set | vendors, customers | The entry has deliberately been put on hold. |
| **Applies-to ID** already set | all | The entry is already assigned to another line, for example in another journal. This prevents an entry from being suggested twice. |
| A journal line applies to the document through **Applies-to Doc. No.** | all | A line in any journal already applies to this document, on the account or on the balancing account. It leaves no mark on the entry, so the suggestion checks the journals themselves. |
| Vendor with **Blocked** *Payment* or *All*, or with a privacy block | vendors | Blocked vendors are not paid. |
| Customer with **Blocked** *All*, or with a privacy block | customers | as for vendors |
| Employee with a privacy block | employees | as for vendors |
| **Payment method** different from the journal batch | all, only in banking journals with a payment method code | The journal batch's payment method determines how the payment is made; entries without their own payment method are included. |

<Callout type="info" title="Employee ledger entries are not filtered by due date">
Employee ledger entries usually have no due date. **Last Due Date** therefore does not affect them; all open employee ledger entries are included, as long as the payment method and the filters match. See [Employee payments](employees.mdx).
</Callout>

Netted entries and an available amount restrict the selection further, and payment discounts can extend it. See [Customer-vendor netting](netting.mdx), [Payment discount](payment-discount.mdx) and [Available amount and vendor priority](budget-priority.mdx).

## How the lines are created

- **Posting Date:** the work date, or the entry's due date if **Use Due Date as Posting Date** is turned on in the template. Entries without a due date get the work date. If **Find Payment Discounts** is also turned on, a line with a payment discount is posted on the payment discount date (the work date at the earliest). See [Payment discount](payment-discount.mdx).
- **Document Type:** *Refund* for customers, *Payment* for vendors and employees.
- **Document No.:** from the journal batch's number series. As in the standard product, the numbers are only calculated in advance and not consumed from the series. This is required because Business Central checks during posting that the document numbers are the next numbers of the series. Without **New Document No. per Line**, all lines share one number.
- **Balancing account:** from the journal batch, as with a line entered manually.
- **Payment Method Code:** the entry's payment method or, if it has none, the journal batch's.
- **Application:** the entries are linked to the line through the **Applies-to ID** and applied when the line is posted. Every line has its own applies-to ID, even when the lines share a document number. Exception: the payment of the remaining amount of a partially netted entry applies to the document through **Applies-to Doc. No.**

## Credit memos

Credit memos are offset and not paid out, because negative payments do not exist. If an account has credit memos, a single payment line is therefore created for the offset amount, settling all entries of the account. This also applies without **Summarize per Account**: if every invoice got its own line, it would be paid in full and the business partner would be overpaid by the amount of the credit memo. Accounts without credit memos keep one line per entry.

If the credit memos exceed the open amounts, no line is created. The entries remain open and are included again in the next run once new invoices exist. Alternatively, you apply them manually.

## Recipient bank account

The line gets the bank account the payment is made to:

1. the vendor's or customer's preferred bank account (**Preferred Bank Account Code**),
2. otherwise, if exactly one bank account exists, the business partner's only bank account,
3. otherwise none. The line can then only be carried out once you have added the bank account.

Members of a [payment group](../../payment-groups.mdx) are paid through the central account. The line gets the central account's bank account, for vendors and customers alike. Employees are paid to the **IBAN** on the employee card.

If the bank account still has the status *New*, the suggestion does not enter it: the line is created without a **Recipient Bank Account**, the run continues, and the closing message states the number of such lines ("… line(s) were created without a recipient bank account, because the bank account of the recipient is not released for payments. …"). **Carry Out Payment** refuses these lines until you release the bank account and select it on the line. It is therefore recommended to release new bank accounts before the run. See [Bank accounts of customers, vendors and employees](../recipient-bank-accounts.mdx).

## See also

- [Extended payment suggestion](../payment-suggestion.mdx)
- [Set up extended payment suggestion templates](templates.mdx)
- [Summarizing and payment reference](purpose.mdx)