import { Callout } from "zudoku/ui/Callout";
# Extended Payment Suggestions
## Business Value
The payment suggestion in standard Microsoft Dynamics 365 Business Central creates payments for **vendors**. Refunds to customers – arising from credit memos or overpayments – and expense reimbursements to **employees** have to be entered manually. In addition, every setting of the suggestion has to be entered again for each run, which is error-prone for recurring payment runs.
If receivables and payables exist with the same business partner at the same time, **netting** is common practice so that only the remaining amount is paid. In the standard product this has to be handled entirely manually, including the required declaration of set-off.
The **extended payment suggestion** in 365 business Banking covers all three account types, stores the settings in templates, and handles customer-vendor netting including the supporting statement.
## Feature Description
The **Suggest Payments** action is available in the **Payment Journal**. It creates journal lines for **customers**, **vendors** and **employees** in a single run.
The call itself only asks for two values:
- **Template Code** – the template that provides the default settings of the suggestion.
- **Last Due Date** – limits the entries taken into account. Leave empty for no limit.
### Extended Payment Suggestion Template
All further settings are stored in the **Extended Payment Suggestion Template** and are therefore reusable:
| Area | Fields |
|---|---|
| Scope | **Suggest Customer Payments**, **Suggest Vendor Payments**, **Suggest Employee Payments** |
| Selection | **Last Due Date Formula**, **Find Payment Discounts**, **Use Vendor Priority**, **Available Amount (LCY)** |
| Summarization | **Summarize per Account**, **New Document No. per Line** |
| Posting | **Use Due Date as Posting Date** |
| Netting | **Apply Customer-Vendor Netting** |
| Purpose | **Customer Message to Recipient**, **Vendor Message to Recipient**, **Employee Message to Recipient** |
| Fine-tuning | **Customer Ledger Entry Filter**, **Vendor Ledger Entry Filter**, **Employee Ledger Entry Filter** |
The three **Message to Recipient** fields are composed from placeholders in curly brackets – just like the posting text of reconciliation rules: `{Document No.}`, `{Account No.}`, `{Account Name}`, `{External Document No.}`, `{Applied Amount}`, `{Document Type}` and `{Document Type Short}`. If a field is left empty, the document type and external document number are used instead. When one payment settles several documents, the document numbers are grouped **per document type** – for example `Credit Memo EGU-1051, Invoice 2026257, 2026345`.
### Credit memos
Credit memos are **offset, not paid out** – there is no such thing as a negative payment. An account holding credit memos is therefore paid by **a single payment line** carrying the offset amount and settling all entries of that account. This also applies when **Summarize per Account** is not set: if every invoice got a line of its own, it would be paid in full and the business partner would be overpaid by the credit memo. Accounts without credit memos keep one line per entry as before.
If the credit memos exceed the open payables, **no** payment line is created. The entries stay open and are picked up by the next run as soon as there are invoices again – or you apply them manually.
A payment that offsets credit memos is never split across several lines, even when **Purpose Exceed Option** is set to *Split Payment* – a chunk consisting only of credit memos would be negative again. If the message does not fit into the 140 characters, a remittance advice is created or the text is trimmed instead.
### Customer-vendor netting
If **Apply Customer-Vendor Netting** is active, the suggestion checks for every vendor whether the corresponding business partner – linked through the contact business relation – is also kept as a customer with **open receivables**. The offsettable amount is the smaller of the open receivables and the suggested payable.
The netted receivables and payables are settled through a **pair of offsetting journal lines** – without a payment through the bank. Only the remaining amount is actually paid.
Each netting run produces a **netting statement** that itemizes the mutual claims with their ledger entries and netted portions and serves as the declaration of set-off. Use the **Print Netting Statement** and **Send Netting Statement** actions in the payment journal to issue it.
Only entries in **local currency** are netted. Members of a [payment group](payment-groups.mdx) are excluded from netting, because their entries are settled through the central account of the group. Vendors holding **credit memos** are excluded as well: the credit memo already reduces the payable and is settled by the offset payment of the account – netting on top of that would settle more than is actually owed.
A posted netting statement is kept as the declaration of set-off, even after the underlying journal lines are gone. The **Netting Statements** list holds all statements.
### Payment Method Code Filter and Fallback
When a **Payment Method Code** is set as a filter criterion in the request dialog of the extended payment suggestion, the suggestion automatically includes entries **without their own payment method code**. Technically, the code appends `|''` to the set filter, so that empty values are included.
For entries without their own payment method code, the **payment method code of the journal batch** (field *bdev.BNK Payment Method Code* in the *Payment Journal*) is used as a fallback. This fallback value is transferred to the created journal lines.
If the payment method code filter is left empty in the dialog, all entries are included anyway – regardless of whether they have a payment method code or not.
Vendor ledger entries without a payment method code can also be manually assigned a payment method code retrospectively. The suggestion then uses the value stored on the ledger entry.
For more information, see [Payment Journal](../../payment-journal.mdx).